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PREFACE 


In  response  to  Air  Force  Secretary  James  G.  Roche’s  charge  to  reinvigorate  the  systems 
engineering  profession,  the  Air  Force  Institute  of  Technology  (AFIT)  undertook  a  broad 
spectrum  of  initiatives  that  included  creating  new  instructional  material.  The  Institute  envisioned 
case  studies  on  past  programs  as  one  of  these  new  tools  for  teaching  the  principles  of  systems 
engineering. 

Four  case  studies,  the  first  set  in  a  planned  series,  were  developed  with  the  oversight  of 
the  Subcommittee  on  Systems  Engineering  to  the  Air  University  Board  of  Visitors.  The 
Subcommittee  included  the  following  distinguished  individuals: 

Chairman 

Dr.  Alex  Levis,  AF/ST 

Members 

Brigadier  General  Tom  Sheridan,  AFSPC/DR 
Dr.  Daniel  Stewart,  AFMC/CD 

Dr.  George  Friedman,  University  of  Southern  California 
Dr.  Andrew  Sage,  George  Mason  University 
Dr.  Elliot  Axelband,  University  of  Southern  California 
Dr.  Dennis  Buede,  Innovative  Decisions  Inc. 

Dr.  Dave  Evans,  Aerospace  Institute 

Dr.  Levis  and  the  Subcommittee  on  Systems  Engineering  crafted  the  idea  of  publishing 
these  case  studies,  reviewed  several  proposals,  selected  four  systems  as  the  initial  cases  for 
study,  and  continued  to  provide  guidance  throughout  their  development.  The  Subcommittee’s 
leading  minds  in  systems  engineering  have  been  a  guiding  force  to  charter,  review,  and  approve 
the  work  of  the  authors.  The  four  case  studies  produced  in  that  series  were  the  C-5  Galaxy,  the 
F-  111,  the  Hubble  Space  Telescope,  and  the  Theater  Battle  Management  Core  System. 

This  second  series  includes  the  B-2  Spirit  Stealth  bomber.  Additional  case  studies  are 
under  consideration  for  future  publication  in  a  third  series. 


Approved  for  Public  Release;  Distribution  Unlimited 


The  views  expressed  in  this  Case  Study  are  those  of  the  author(s)  and  do  not  reflect  the 
official  policy  or  position  of  the  United  States  Air  Force,  the  Department  of  Defense,  or  the 

United  States  Government. 
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FOREWORD 


At  the  direction  of  the  Secretary  of  the  Air  Force,  Dr.  James  G.  Roche,  the  Air  Force 
established  a  Center  for  Systems  Engineering  (CSE)  at  the  Air  Force  Institute  of  Technology 
(AFIT)  campus  on  Wright-Patterson  AFB,  OH  in  2002.  With  academic  oversight  by  a 
Subcommittee  on  Systems  Engineering,  chaired  by  Air  Force  Chief  Scientist  Dr.  Alex  Levis,  the 
CSE  was  tasked  to  develop  case  studies  focusing  on  the  application  of  systems  engineering 
principles  within  various  aerospace  programs.  The  committee  drafted  an  initial  case  outline  and 
learning  objectives,  and  suggested  the  use  of  the  Friedman-Sage  Framework  to  guide  overall 
analysis. 

The  CSE  contracted  for  management  support  with  Universal  Technology  Corporation 
(UTC)  in  July  2003.  Principal  investigators  for  the  four  case  studies  published  in  the  initial 
series  included  Mr.  John  Griffin  for  the  C-5A,  Dr.  G.  Keith  Richey  for  the  F-l  11,  Mr.  James 
Mattice  for  the  Hubble  Space  Telescope,  and  Mr.  Josh  Collens  from  The  MITRE  Corporation  for 
the  Theater  Battle  Management  Core  System  effort.  These  cases  were  published  in  2004  and  are 
available  on  the  CSE  website. 

The  Department  of  Defense  continues  to  develop  and  acquire  joint  complex  systems  that 
deliver  needed  capabilities  demanded  by  our  warfighters.  Systems  engineering  is  the  technical 
and  technical  management  process  that  focuses  explicitly  on  delivering  and  sustaining  robust, 
high-quality,  affordable  products.  The  Air  Force  leadership,  from  the  Secretary  of  the  Air  Force, 
to  our  Service  Acquisition  Executive,  through  the  Commander  of  Air  Force  Materiel  Command, 
has  collectively  stated  the  need  to  mature  a  sound  systems  engineering  process  throughout  the 
Air  Force. 

Plans  exist  for  future  case  studies  focusing  on  other  areas.  Suggestions  have  included 
other  Joint  service  programs,  logistics-led  programs,  science  and  technology/laboratory  efforts, 
additional  aircraft  programs,  and  successful  commercial  systems. 

As  we  uncovered  historical  facts  and  conducted  key  interviews  with  program  managers 
and  chief  engineers,  both  within  the  government  and  those  working  for  the  various  prime  and 
subcontractors,  we  concluded  that  systems  programs  face  similar  challenges  today.  Applicable 
systems  engineering  principles  and  the  effects  of  communication  and  the  environment  continue 
to  challenge  our  ability  to  provide  a  balanced  technical  solution.  We  look  forward  to  your 
comments  on  this  B-2  case,  our  other  AF  CSE  published  studies,  and  others  that  will  follow. 


MARK  K.  WILSON,  SES 

Director,  AF  Center  for  Systems  Engineering 
Air  Force  Institute  of  Technology 
http://cse.afit.edu/ 


PROLOGUE 


The  B-2  is  a  phenomenal  weapon  system. . .  born  out  of  the  cold  war  as  a  strategic  nuclear 
penetrator...  now  proving  it’s  worth  with  a  wide  range  of  tactical  precision  weapon  delivery 
capabilities.  This  case  study  deals  with  the  early  Full  Scale  Development  (FSD)  and  Engineering 
Manufacturing  Development  (EMD)  phases  of  the  program,  known  today  as  System  Design  and 
Development  (SDD). .  .there  is  a  subtle  but  important  difference. .  .did  you  catch  it?  Hopefully,  as 
you  work  through  this  case  study,  you  see  that  the  System  Engineering  process  applied  on  the  B- 
2  program  from  1979  (as  the  Advanced  Technology  Bomber  requirements  definition  phase) 
through  completion  of  the  first  airplane  build  played  a  significant  role  in  bringing  about  the 
superior  capability  the  system  has  today;  not  just  in  the  design  of  the  airplane,  but  also  the  in  the 
development  of  new  manufacturing  processes  as  well. 

I  was  privileged  to  serve  as  the  Program  Director  from  June  1983  (just  as  the  decision  to 
redesign  the  airplane  was  being  made)  to  June  1991.  There  were  a  number  of  programmatic 
issues  that  faced  the  program  throughout  this  time  period;  and  without  the  Systems  Engineering 
process  described  in  the  case  study,  we  would  not  have  had  the  necessary  quantitative  data  to  be 
able  to  adequately  address  these  programmatic  issues  in  an  authoritative  way.  The  task  of  totally 
redesigning  the  aircraft  two  years  into  the  program,  having  completed  Preliminary  Deign  Review 
#1,  while  striving  to  maintain,  or  minimize,  program  impacts  was  a  Herculean  task.  Because  of 
the  System  Engineering  process  discussed  in  this  case  study,  with  the  discipline  and  integrity  that 
existed  in  the  process,  the  B-2  Program  was  able  to  maintain  the  technical  baseline  across  the 
entire  government/contractor  team  and  by  so  doing  minimized  the  eventual  impacts.  The  key 
factor  in  accomplishing  this,  after  the  professionalism  and  dedication  of  all  the  people  involved, 
was  the  fact  that  the  program  had  only  ONE  (near  real  time)  design  data  base;  which  all  of  the 
program  participants  utilized... engineering,  manufacturing,  test,  sub-contractors,  and  the 
government.  As  System  Engineers,  and  particularly  as  Chief  System  Engineers,  maintaining  the 
technical  baseline  will  be  the  most  important  part  of  your  job. . .  without  it,  the  programmatic 
impacts  will  begin  to  accumulate  to  the  point  where  the  program  will  eventually  become  at  risk. 

I  want  to  emphasize  at  this  point  that  there  is  a  difference  between  System  Engineering 
roles  and  responsibilities  and  Program  Management  roles  and  responsibilities...  both  are 
important  to  the  success  of  a  program. . .  but  Program  Directors  can  not  succeed  without  a  sound 
technical  baseline  and  a  solid  System  Engineering  process.  The  most  important  responsibility  for 
the  System  Engineer  is  to  maintain  the  integrity  of  the  technical  baseline,  regardless  of 
programmatic  issues;  because  it  is  absolutely  fundamental  to  the  integrity  of  the  program 
management  baseline. 


Richard  M.  Scofield,  Lt  Gen,  USAF,  Ret 
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EXECUTIVE  SUMMARY 


The  B-2  Systems  Engineering  Case  Study  describes  the  application  of  systems 
engineering  during  the  concept  exploration,  design,  and  development  of  the  USAF  B-2  Spirit 
stealth  bomber.  The  case  examines  and  explores  the  systems  engineering  process  as  applied  by 
the  Air  Force  B-2  System  Program  Office,  the  prime  contractor,  Northrop,  and  the  two  major 
subcontractors,  Boeing  and  Vought,  from  the  program’s  genesis  in  the  late  1970s  to  the  first 
flight  of  the  first  aircraft  on  17  July  1989.  The  systems  engineering  process  is  traced  from  a 
vision  of  a  few  planners  in  1978  to  the  production  of  21  operational  aircraft  that  are  currently 
serving  our  nation.  Numerous  interviews  were  conducted  with  the  principals  who  managed  and 
directed  the  program  and  a  story  of  the  systems  engineering  process  emerged. 

The  B-2  was  conceived  to  profit  from  the  advances  in  stealth  technology  that  grew  from  a 
series  of  laboratory  experiments  and  design  studies  during  1970  to  1976.  The  early  work  by  both 
the  government  and  industry  during  this  timeframe  resulted  in  feasible  and  practical  stealth 
vehicles  that  exist  throughout  our  military.  The  current  operational  fleets  of  fighters,  bombers, 
UAVs,  ships,  and  other  stealth  vehicles  trace  their  heritage  to  the  early  technology  maturation 
and  engineering  development  programs.  Stealth  (or  low  observables,  as  it  was  called  by  the 
original  practitioners)  offered  a  new  and  revolutionary  approach  for  penetrating  the  burgeoning 
growth  of  the  Soviet  defensive  system  of  an  integrated  radar  network.  The  fighter  was  the  first 
type  of  weapon  system  to  be  studied  for  the  benefits  of  stealth  and  the  pay-off  was  assessed  as 
substantial.  The  bomber  was  the  next  obvious  candidate,  and  it  too,  showed  great  promise. 
Lockheed  was  in  the  lead  for  the  technology  application  for  fighters  and  was  awarded  the 
development  contract  for  the  F-l  17  stealth  fighter.  Northrop  and  Lockheed  were  competitors  for 
the  contract  to  develop  the  stealth  bomber  from  late  1979;  Northrop  won  the  contract  in 
November  1981.  The  first  flight  of  the  B-2  was  17  July  1989  with  the  first  operational  sortie  of 
the  aircraft  occurring  during  the  Balkan  conflict  in  December  1995. 

The  Spirit  is  a  long-range  heavy  bomber  incorporating  the  key  technologies  of  the  time. 
First,  as  evident  in  Figure  1,  it  is  a  highly  efficient  flying-wing  (tailless)  aeronautical  design. 
Secondly,  the  aircraft  makes  extensive  use  of  composite  materials.  And  third,  it  is  designed  for 
stealth.  Figure  1  shows  four  views  of  the  aircraft  with  each  view  showing  the  details  of  the 
control  surfaces,  doors,  access  panels,  and  other  external  features.  Note  the  center  of  the  aircraft 
from  the  bottom  view,  showing  the  large  cut  out  of  the  structure  to  accommodate  the  weapons 
bay  doors  (4),  engine  access  doors  (4),  and  the  main  landing  gear  doors  (2).  The  ability  to 
achieve  an  efficient  structural  design  in  the  presence  of  the  large  cutouts  on  the  bottom  skin  of 
the  vehicle  is  one  of  the  significant  achievements  of  the  structures  team. 

The  B-2  has  significant  range  perfonnance  and  payload  capability.  Table  1  shows  the 
design  weights  and  the  range  and  payloads  for  the  nuclear  mission  as  well  as  the  conventional 
missions.  The  bomber  was  primarily  designed  as  a  long-range  strategic  nuclear  delivery  system, 
but  a  significant  conventional  capability  was  designed  in  from  the  beginning.  The  table  shows 
an  abbreviated  list  of  weapons  currently  certified  for  carriage.  The  list  of  weapons  carriage 
capability  continues  to  expand  through  ongoing  B-2  modernization  programs. 


VI 


Figure  1.  External  View  Drawings  of  the  B-2  Aircraft  [1] 

Systems  engineering  was  applied  to  the  B-2  consistent  with  the  maturity  of  the  discipline 
circa  1978-1990  (the  time  frame  of  interest  for  this  case  study).  The  technical  field  of  systems 
engineering  was  systemic  with  the  design  process  throughout  many  aerospace  companies. 
However,  this  was  also  the  timeframe  for  continued  recognition  by  the  Air  Force  for  the  need  for 
more  formal  documentation,  tools,  procedures,  and  organizational  structure,  initiated  in  the  mid 
1960s  with  the  publication  of  both  the  Air  Force  Systems  Command  AFSC-375  series  of 
Manuals  and  the  issuance  of  the  systems  engineering  military  standard,  MIL-STD-490A.  It  was 
also  a  time  that  concurrent  engineering  was  in  vogue  in  commercial  ventures.  This  movement 
was  an  attempt  to  capture  the  Air  Force  and  defense  industry’s  recognition  of  the  needs  of 
logistics,  manufacturing,  supportability,  and  reliability  in  the  early  design  effort.  The  degree  to 
which  programs  followed  the  emerging  fonnality  of  systems  engineering  was  a  function  of  the 
maturity  of  the  systems  engineering  process  in  the  companies  involved  in  the  project,  the  effort 
demanded  by  the  procuring  agency  through  emphasis  in  the  Statement  of  Work,  and  the  degree 
to  which  the  design  and  subsystems  specialists  within  the  project  were  schooled  and  committed 
to  systems  engineering. 
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Table  1.  B-2  Weight  and  Performance  Capabilities  [1] 


Features 

Length 

69  feet 

Height 

17  feet 

Wingspan 

172  feet 

Power  plant 

4  GE  F-l  18  engines  (17,300  lbs  thrust  each) 

Crew 

Two  pilots 

Weight  Capability 

Max  takeoff  Weight 

Max  in-flight  Weight 

Max  Landing  Weight 

336.500  pounds 

357.500  pounds 

31 1.500  Pounds 

Max  payload 

44,000  pounds 

Max  fuel 

166,900  pounds 

Min  Flying  Weight 

Weight  Empty 

161,385  pounds 

149,900  pounds 

Performance  Capability 

Cruise  performance 

6,000  NM,  unrefueled  at  high  altitude 

Airport  performance 

Takeoff,  Std  day,  Sea  Level 
Landing,  240,000  Pounds 

8,000  feet  at  maximum  takeoff  weight 

5,000  feet 

Weapons  Payload 

Nuclear  payload 

16B-83 

16  B-61-7 

8  B-61-1 1 

Conventional  payload 

16  GBU-31  (JD AM-84) 

80  GBU-38  (JD AM-82) 

16  AGM-154A  (JSOW-97) 

The  application  of  the  systems  engineering  process  on  the  B-2  program  benefited 
profoundly  by  an  important  early  decision  to  integrate  the  customer’s  requirements  development 
process  into  the  company  teams’  design  and  development  process.  This  resulted  in  a  culture  of 
continual  systems  engineering  trade  studies  from  the  very  top-level  systems  requirements  down 
to  the  simplest  design  details  that  affected  all  aspects  of  the  aircraft  design,  maintenance, 
supportability,  and  training.  Specialists  from  the  technical  and  management  disciplines  worked 
as  a  team  to  assess  the  need  for  a  specific  performance  level  of  a  requirement  to  enhance 
operational  effectiveness  or  trade  for  a  lower  level  of  performance  to  reduce  cost  or  risk.  The 
team  could  balance  the  benefit  of  achieving  a  performance  level  against  its  impact  on  cost, 
schedule,  and  risk  and  present  the  results  to  the  proper  decision  tier  for  action. 

The  advantages  of  the  systems  engineering  being  systemic  to  the  operation  of  the 
development  program  through  the  1980s  were: 


Multiple  systems-level  trade  studies.  Systems  engineering  trade  studies  occurred  for 
all  technical  disciplines,  subsystems  and  at  all  levels  of  the  work  breakdown  structure 
(WBS) 


•  Balanced  perfonnance,  cost,  schedule,  and  risk 

•  Agreement  on  the  tasks  to  be  performed  and  their  priority 

•  Well  understood  and  documented  customer/supplier  agreements. 

In  order  to  take  advantage  of  the  benefits  that  accrued  from  the  integration  of  the 
requirements  and  the  design/development  processes,  other  program  initiatives  and  decisions 
making  process  were  crucial,  including: 

•  Rapid  decision  process  with  the  ability  to  get  the  proper  infonnation  to  the  proper 
level,  followed  by  timely  action 

•  An  organizational  structure  that  utilized  a  system  view  to  assess  impacts 

•  Skilled  professionals  at  all  levels  and  in  all  technical  and  management  disciplines 

•  Processes  to  accurately  assess,  assign,  track,  integrate,  and  close  risks. 

The  organizational  structures  at  the  contractors  (Northrop,  Boeing,  Vought,  Hughes, 
General  Electric,  etc.)  and  government  agencies  (Aeronautical  Systems  Division,  the  B-2 
Program  Office,  and  the  Strategic  Air  Command)  were  critical  to  the  success  of  the  program. 

The  Air  Force  Systems  Program  Office  (SPO)  organization  was  a  “classic”  functional  structure 
with  a  strong  integration  process  that  utilized  the  top  two  levels  of  the  organization  as  the 
primary  programmatic  decision-making  body.  The  contractors  used  a  combination  of  strong 
project  offices,  along  wit  functional  organizations  to  provide  the  decision  base  and  the  leadership 
for  the  program. 

There  were  several  different  systems  engineering  organizations  in  each  major  functional 
organization.  The  workforce  was  arranged  in  WBS  task  teams,  similar  in  construct  to  the 
Integrated  Product  Teams  (IPT)  to  follow  in  the  future,  but  with  some  fundamental  differences. 
These  WBS  task  teams  were  the  critical  functioning  structure  and  were  the  primary  process  by 
which  business  was  conducted  throughout  the  development  program.  Risk  Closure  Plans  were  a 
key  management  process  and  were  instrumental  in  providing  focus  to  risk  identification, 
tracking,  and  closure.  Thus,  the  organizational  structure,  the  WBS  task  team  construct,  the 
decision  making  process,  the  risk  closure  planning  process,  the  systems  engineering  tools,  and 
the  dedicated,  talented,  experienced  people  in  engineering,  all  the  functional  areas,  and  program 
management  were  essential  features  of  the  systems  engineering  process  during  the  development 
process  of  the  B-2. 

The  Five  B-2  Learning  Principles 

The  learning  principles  are  those  key  factors  that  the  authors  considered  as  the  most 
influential  to  the  successful  outcomes  and  to  the  failures  of  the  program.  They  are  developed  in 
further  detail,  by  following  the  chronological  evolution  of  the  program.  In  Section  4,  the 
learning  principles  are  then  summarized  and  further  emphasized  as  to  why  they  were  chosen  as 
the  major  points. 

LP  1 ,  Integration  of  the  Requirements  and  Design  Processes:  A  key  aspect  of  the 
implementation  of  the  systems  engineering  process  was  the  integration  of  the  SPO 
requirement’s  team  with  the  contractors’  work  breakdown  structure  (WBS)  Task 
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teams  into  a  cohesive  program  effort.  These  contractor  teams  included  design, 
manufacturing,  Quality  Assurance,  and  logistics.  This  integration  facilitated  continual 
trade  studies  conducted  by  the  specialists  from  the  User/SPO  government  team  with 
the  company  specialists  to  fully  assess  the  performance  trade-offs  against  schedule, 
cost,  and  risk. 

LP  2,  WBS  Task  Teams  and  Functional  Hierarchy:  A  well-defined  contract  work 
breakdown  structure  (WBS)  stipulated  the  entire  program  content  and  tasking.  The 
company  organized  the  design/development  effort  into  multiple  teams,  responsible  to 
implement  the  WBS  for  sections  of  the  air  vehicle  and  for  each  subsystem.  These 
WBS  Task  Teams  were  assigned  complete  work  packages,  for  example,  the  forward 
center  wing.  The  systems  engineering  WBS  Task  Team  efforts  were  organized 
similarly,  but  with  separate  responsibilities,  each  reporting  to  the  Northrop  chief 
engineer  or  his  deputies.  The  functional  organizations  assigned  members  to  the  task 
teams  to  assure  accommodation  of  their  program  needs.  A  vital  distinction  from 
many  of  today’s  IPTs  was  retaining  the  WBS  Task  Team  membership  throughout  the 
functional  organizations’  various  management  levels.  This  facilitated 
communication,  integration,  interfaces,  and  integrated  the  functional  leadership  of 
each  of  the  company’s  technical  and  management  disciplines  into  the  decision 
process.  The  program  management  top-level  structure  was  organized  into  a  strong 
project  office  with  centralized  decision  authority  and  strong  leadership  at  the  top  of 
both  the  SPO  and  the  contractor  organizations. 

LP  3,  Air  Vehicle  Reconfiguration:  When  the  identification  of  a  major  aeronautical 
control  inadequacy  was  discovered  just  four  months  prior  to  fonnal  configuration 
freeze,  an  immediate  refocus  of  the  Task  Teams  was  required.  Within  several  days, 
the  air  vehicle  task  teams  were  conducting  trade  studies,  augmenting  their  skill  sets, 
and  integrating  with  the  other  program  participants  in  a  coordinated  effort  to  derive 
an  efficient,  controllable,  operationally  useful  system.  At  the  same  time,  the  program 
elements  that  were  not  markedly  affected  by  the  change  maintained  a  course  that 
preserved  their  schedule,  but  was  sufficiently  flexible  to  include  any  potential 
changes.  In  a  program  wide  systems  engineering  effort,  the  prime  contractor’s 
program  office  integrated  the  teams,  reviewed  their  efforts,  coordinated  the  systems 
trades,  and  identified  significant  changes  to  the  outer  mode  lines,  the  radar  cross 
section  (RCS)  baseline,  all  major  structure  assemblies,  and  all  major  air  vehicle 
subsystems  requirements,  with  the  exception  of  avionics  and  armament.  The 
alternatives  were  derived  by  the  end  of  the  third  month,  the  final  choice  was  selected 
by  the  sixth  month,  and  the  seventh  month  was  used  to  coordinate  and  garner  the 
approval  of  all  stakeholders.  While  the  program  response  to  the  crisis  was  rapid  and 
effective,  and  a  significant  impact  on  the  downstream  cost  and  schedule  was 
anticipated  by  the  management  team,  and  the  technical  impact  was  predicted  by  the 
systems  engineering  process,  it  was  not  predicted  to  the  fullest  extent. 

LP  4,  Subsystem  Maturity:  The  effect  of  the  reconfiguration  on  the  maturity  of  all  the  air 
vehicle  subsystems  (flight  control,  environmental  control,  electrical,  landing  gear, 
etc)  was  far  greater  than  projected.  The  subsystems  were  mostly  vendor-supplied 
equipments  and  some  were  in  the  selection  process  to  the  technical  requirements  of 
the  original  baseline  when  the  reconfiguration  occurred.  After  the  new  configuration 
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was  derived,  the  requirements  for  the  subsystems  changed  to  such  a  degree  that  they 
had  to  be  resized  and  repackaged.  It  took  longer  than  anticipated  by  the  systems 
engineering  process  to  recognize  the  growing  problem  of  getting  all  the  specifications 
updated  and  to  identity  the  lagging  equipment  maturity  that  resulted.  Thus,  the 
reconfiguration  required  a  second  iteration  of  the  design  requirements  and  their  flow- 
down  to  the  many  suppliers  and  their  detailed  designs.  These  iterations  after  PDR-2 
resulted  in  the  vehicle  subsystems  not  achieving  their  Critical  Design  Review  (CDR) 
milestone  concurrently  with  the  structure,  but  rather  five  months  later. 

LP  5,  Risk  Planning  and  Management:  The  program  was  structured  so  that  risks 
affecting  the  viability  of  the  weapons  system  concept  were  identified  at  contract 
award  and  were  structured  as  part  of  the  Program  and  WBS  work  plans.  The  initial 
risks  were  comprised  of  those  “normal”  risks  associated  with  a  large  complex 
weapons  system  development  as  well  as  the  new  technology  and  processes  necessary 
to  mature  the  program  to  low  to  medium  risk  at  PDR.  Those  initial  risks  were  closed 
prior  to  PDR  2.  The  risk  closure  process  continued  throughout  development  and 
identified  new  risks  and  continuously  identified  new  risk  closure  plans.  Most 
importantly,  the  work  associated  with  risk  closure  for  each  plan  was  integrated  into 
the  WBS  task  teams’  work  plans  and  into  the  Program  Plans.  These  detailed  plans 
showed  all  design,  analyses,  tests,  tooling,  and  other  tasks  necessary  to  close  the 
identified  risks  and  were  maintained  as  part  of  the  normal  design/program  reporting 
activity. 

The  Friedman-Sage  [2]  Framework  was  used  to  examine  the  context  of  all  the  learning 
principles,  their  primary  responsibility  and  their  overall  effect  on  the  program.  The  Friedman- 
Sage  construct  and  its  associated  matrix  of  nine  Concept  Domains  and  Three  Responsibility 
Domains  gives  the  systems  engineering  practitioner  a  powerful  tool  to  examine  a  program’s 
systems  engineering  effort. 

As  the  reader  delves  into  the  full  story  of  the  B-2,  it  is  important  to  keep  in  mind  the 
environment  surrounding  the  program.  Conducted  in  utmost  secrecy,  it  can  be  compared  to  the 
Manhattan  Project  of  WWII  that  developed  the  atomic  bomb.  Security  was  the  most  important 
consideration.  In  fact,  the  Program  Management  Directive  (PMD)  specified  the  order  of 
program  priority  as: 

1.  Security 

2.  Performance 

3.  Schedule,  and 

4.  Cost. 

The  program  was  part  of  the  Reagan  weapons  build-up,  along  with  the  B-1B  and  Peacekeeper 
Missile  System  in  the  early  1980s.  This  build-up  can  be  considered  to  have  caused  the  instability 
in  the  Soviet  Union  that  eventually  led  to  the  collapse  of  that  country  and  the  end  of  the  Cold 
War  on  9  November  1989  with  the  fall  of  the  Berlin  Wall. 
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1.0  SYSTEMS  ENGINEERING  PRINCIPLES 

1.1  General  Systems  Engineering  Process 

1.1.1  Introduction 

The  Department  of  Defense  continues  to  develop  and  acquire  systems  to  provide  needed 
capabilities  to  the  warfighter.  With  a  constant  objective  to  improve  the  acquisition  process,  it 
strives  at  new  and  creative  ways  to  acquire  these  technically  complex  systems.  A  sound  systems 
engineering  process,  focused  explicitly  on  delivering  and  sustaining  robust,  high-quality, 
affordable  products  that  meet  the  needs  of  customers  and  stakeholders  must  continue  to  evolve 
and  mature.  Systems  engineering  is  the  technical  and  technical  management  process  that  results 
in  delivered  products  and  systems  that  exhibit  the  best  balance  of  cost,  schedule,  and 
performance.  The  process  must  operate  effectively  with  desired  mission-level  capabilities, 
establish  system-level  requirements,  allocate  these  down  to  the  lowest  level  of  the  design,  and 
assure  validation  and  verification  of  performance,  meeting  cost  and  schedule  constraints.  The 
systems  engineering  process  changes  as  the  program  progresses  from  one  phase  to  the  next,  as  do 
the  tools  and  procedures.  The  process  also  changes  over  the  decades,  maturing,  expanding, 
growing,  and  evolving  from  the  base  established  during  the  conduct  of  past  programs.  Systems 
engineering  has  a  long  history.  Examples  can  be  found  demonstrating  a  systemic  application  of 
effective  engineering  and  engineering  management,  as  well  as  poorly  applied,  but  well  defined 
processes.  Throughout  the  many  decades  during  which  systems  engineering  has  emerged  as  a 
discipline,  many  practices,  processes,  heuristics,  and  tools  have  been  developed,  documented, 
and  applied. 

Several  core  lifecycle  stages  have  surfaced  as  consistently  and  continually  challenging 
during  any  system  program  development.  First,  system  development  must  proceed  from  a  well- 
developed  set  of  requirements.  Secondly,  regardless  of  the  evolutionary  acquisition  approach, 
the  system  requirements  must  flow  down  to  all  subsystems  and  lower  level  components.  And 
third,  the  system  requirements  need  to  be  stable,  balanced  and  must  properly  reflect  all  activities 
in  all  intended  environments.  However,  system  requirements  are  not  unchangeable.  As  the 
system  design  proceeds,  if  a  requirement  or  set  of  requirements  is  proving  excessively  expensive 
to  satisfy,  the  process  must  rebalance  schedule,  cost,  and  performance  by  changing  or  modifying 
the  requirements  or  set  of  requirements. 

Systems  engineering  includes  making  key  system  and  design  trades  early  in  the  process 
in  order  to  establish  the  system  architecture.  These  architectural  artifacts  can  depict  any  new 
system,  legacy  system,  modifications  thereto,  introduction  of  new  technologies,  and  overall 
system-level  behavior  and  performance.  Modeling  and  simulation  are  generally  employed  to 
organize  and  assess  architectural  alternatives  at  this  introductory  stage.  System  and  subsystem 
design  follows  the  functional  architecture.  System  architectures  are  modified  if  the  elements  are 
too  risky,  expensive  or  time-consuming.  Both  newer  object-oriented  analysis  and  design  and 
classic  structured  analysis  using  functional  decomposition  and  infonnation  flows/data  modeling 
occurs.  Design  proceeds  logically  using  key  design  reviews,  tradeoff  analysis,  and  prototyping 
to  reduce  any  high-risk  technology  areas  [3,  Colombi]. 

Important  to  the  efficient  decomposition  and  creation  of  the  functional  and  physical 
architectures  and  designs  are  the  management  of  interfaces  and  integration  of  subsystems.  This 
is  applied  to  subsystems  within  a  system,  or  across  large,  complex  systems  of  systems.  Once  a 
solution  is  planned,  analyzed,  designed,  and  constructed,  validation  and  verification  take  place  to 
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assure  the  requirements  have  been  satisfied.  Definition  of  test  criteria,  measures  of  effectiveness 
(MOEs),  and  measures  of  performance  (MOPs),  established  as  part  of  the  requirements  process, 
take  place  well  before  any  component  or  subsystem  assembly  design  and  construction  occurs. 

There  are  several  excellent  representations  of  the  systems  engineering  process  presented 
in  the  literature.  These  depictions  present  the  current  state  of  the  art  in  the  maturity  and 
evolution  of  the  systems  engineering  process.  One  can  find  systems  engineering  process 
definitions,  guides,  and  handbooks  from  the  International  Council  on  Systems  Engineering 
(INCOSE),  European  Industrial  Association  (EIA),  Institute  of  Electrical  and  Electronics 
Engineers  (IEEE),  and  various  Department  of  Defense  (DoD)  agencies  and  organizations.  They 
show  the  process  as  it  should  be  applied  by  today’s  experienced  practitioner.  One  of  these 
processes,  long  used  by  the  Defense  Acquisition  University  (DAU),  is  depicted  by  Figure  1-1.  It 
should  be  noted  that  this  model  is  not  accomplished  in  a  single  pass.  This  iterative  and  nested 
process  gets  repeated  to  the  lowest  level  of  definition  of  the  design  and  its  interfaces. 
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Figure  1-1.  The  Systems  Engineering  Process,  Defense  Acquisition  University 

The  DAU  model,  like  all  others,  has  been  documented  in  the  last  two  decades,  and  has 
expanded  and  developed  to  reflect  the  changing  environment.  Systems  are  becoming 
increasingly  complex  internally  and  more  interconnected  externally.  The  process  used  to 
develop  the  aircraft  and  systems  of  the  past  was  a  process  effective  at  the  time.  It  served  the 
needs  of  the  practitioners  and  resulted  in  many  successful  systems  in  our  inventory. 
Notwithstanding,  the  cost  and  schedule  performance  of  the  past  programs  include  examples  of 
some  well-managed  programs  and  ones  with  less  stellar  execution.  As  the  nation  entered  the 
1980s  and  1990s,  large  DoD  and  commercial  acquisition  programs  were  overrunning  costs  and 
were  behind  schedule.  The  aerospace  industry  and  its  organizations  were  becoming  larger  and 
were  more  geographically  distributed  and  culturally  diverse.  Large  aerospace  companies  have 
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worked  diligently  to  establish  common  systems  engineering  practices  across  their  enterprises. 
However,  these  common  practices  must  be  understood  and  be  useful  to  the  enterprise  and  across 
multiple  corporations  because  of  the  mega-trend  of  teaming  in  large  (and  some  small)  programs. 
It  is  essential  that  the  systems  engineering  process  effect  integration,  balance,  allocation,  and 
verification  and  be  useful  to  the  entire  program  team  down  to  the  design  and  interface  level. 

Today,  many  factors  overshadow  new  acquisition,  including  the  system-of-systems  (SoS) 
context,  network  centric  warfare  and  operations,  and  the  rapid  growth  in  information  technology. 
These  factors  are  driving  a  more  sophisticated  systems  engineering  process  with  more  complex 
and  capable  features,  along  with  new  tools  and  procedures.  One  area  of  increased  focus  of  the 
systems  engineering  process  is  the  information  systems  architectural  definitions  used  during 
system  analysis.  This  process,  described  in  the  DoD  Architectural  Framework  (DoDAF)  [4], 
emphasizes  greater  reliance  on  reusable  architectural  views  describing  the  system  context, 
concept  of  operations,  interoperability,  information  and  data  flows  and  network  service-oriented 
characteristics. 

1.1.2  Case  Studies 

The  systems  engineering  process  to  be  used  in  today’s  complex  systems  and  system-of- 
systems  projects  is  a  process  matured  and  founded  on  principles  developed  in  the  past. 
Examination  of  systems  engineering  principles  used  on  programs,  both  past  and  present,  can 
provide  a  wealth  of  lessons  to  be  used  in  applying  and  understanding  today’s  process.  It  was  this 
thinking  that  led  to  the  construction  of  the  AF  CSE  case  studies. 

The  purpose  of  developing  detailed  case  studies  is  to  support  the  teaching  of  systems 
engineering  principles.  They  will  facilitate  learning  by  emphasizing  to  the  student  the  long-term 
consequences  of  the  systems  engineering  as  it  influences  program  decisions,  thereby  influencing 
program  success.  Systems  engineering  case  studies  assist  in  discussion  of  both  successful  and 
unsuccessful  methodologies,  processes,  principles,  tools,  and  decision  material  to  assess  the 
outcome  of  alternatives  at  the  program/system  level.  In  addition,  the  importance  of  using  skills 
from  logistics,  manufacturing,  finance,  contracts,  Quality  Assurance,  and  engineering  disciplines 
and  then  collecting,  assessing,  and  integrating  varied  functional  data  are  emphasized.  When  they 
are  taken  together,  the  student  is  provided  real-world  detailed  examples  of  how  the  process 
contributes  to  the  effective  balance  of  cost,  schedule,  and  performance. 

The  utilization  and  mis-utilization  of  systems  engineering  principles  are  highlighted,  with 
special  emphasis  on  the  conditions  that  both  foster  and  impede  good  systems  engineering 
practice.  Case  studies  should  be  used  to  illustrate  both  good  and  bad  examples  of  acquisition 
management  and  learning  principles,  to  include  whether: 

•  Every  system  provides  a  satisfactory  balanced  and  effective  product  to  a  customer 

•  Effective  requirements  analysis  was  applied 

•  Consistent  and  rigorous  application  of  systems  engineering  management  standards 
was  applied 

•  Effective  test  planning  was  accomplished 

•  There  were  effective  major  technical  program  reviews 

•  Continuous  risk  assessments  and  management  was  implemented 

•  There  were  reliable  cost  estimates  and  policies 

•  They  used  disciplined  application  of  configuration  management 

•  A  well  defined  system  boundary  was  defined 
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•  They  used  disciplined  methodologies  for  complex  systems 

•  Problem  solving  incorporated  understanding  of  the  system  within  bigger  environment 
(customer’s  customer) 

The  systems  engineering  process  transforms  an  operational  need  into  a  system  or  system- 
of-systems.  Architectural  elements  of  the  system  are  allocated  and  translated  into  detailed  design 
requirements  by  the  systems  engineering  process.  The  systems  engineering  process,  from  the 
identification  of  the  operational  need,  through  the  development,  and  to  utilization  of  the  product, 
must  continuously  integrate  and  balance  the  requirements,  while  giving  consideration  to  the  cost 
and  schedule  to  provide  an  operationally  effective  system  throughout  its  lifecycle.  Systems 
engineering  case  studies  highlight  the  various  interfaces  and  communications  to  achieve  this 
balance,  which  include: 

•  The  program  manager/sy stems  engineering  interface  essential  between  the 
operational  user  and  developer  (acquirer)  to  translate  the  needs  into  the  performance 
requirements  for  the  system  and  subsystems. 

•  The  government/contractor  interface  essential  for  the  practice  of  systems  engineering 
to  translate  and  allocate  the  performance  requirements  into  detailed  requirements. 

•  The  developer  (acquirer)/industry/user  interface  within  the  project,  essential  for  the 
systems  engineering  practice  of  integration  and  balance. 

The  systems  engineering  process  must  manage  risk,  both  known  and  unknown,  as  well  as 
both  internal  and  external.  Identifying,  integrating,  and  managing  the  internal  risks  within  the 
scope  of  the  directed  program  is  an  essential  task  of  the  systems  engineering  process.  A  second 
responsibility  of  the  process  is  to  quickly  and  accurately  respond  when  asked  to  evaluate 
proposed  changes  to  the  directed  program,  external  risks.  The  process  must  advise  the  program 
decision  makers  as  to  the  consequences  of  proposed  changes  that  may  be  imposed  by  external 
forces.  The  objective  of  this  second  responsibility  will  specifically  capture  those  external  factors 
and  the  impact  of  these  uncontrollable  influences,  such  as  actions  of  Congress,  changes  in 
funding,  new  instructions/policies,  changing  stakeholders  or  user  requirements  or  contractor  and 
government  staffing  levels. 

Lastly,  the  systems  engineering  process  must  respond  to  “Mega-Trends”  in  the  systems 
engineering  discipline  itself,  as  the  nature  of  systems  engineering  and  related  practices  do  vary 
with  time  and  circumstances. 

1.1.3  Framework  for  Analysis 

This  case  study  presents  learning  principles  specific  to  the  B-2  using  the  Friedman-Sage 
framework  [2]  to  organize  the  assessment  of  the  application  of  the  systems  engineering  process. 
The  framework  and  the  derived  matrix  play  an  important  role  in  developing  case  studies  in 
systems  engineering  and  systems  management.  It  describes  a  nine  row  by  three  column  matrix 
shown  in  Table  1-1. 
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Table  1-1.  A  Framework  of  Key  Systems  Engineering  Concepts  and  Responsibilities  [2] 


Concept  Domain 

Responsibility  Domain 

1.  Contractor 
Responsibility 

2.  Shared 
Responsibility 

3.  Government 
Responsibility 

A. 

Requirements  Definition  and 
Management 

B. 

Systems  Architecting  and  Conceptual 
Design 

C. 

System  and  Subsystem  Detailed 

Design  and  Implementation 

D. 

Systems  and  Interface  Integration 

E. 

Validation  and  Verification 

F. 

Deployment  and  Post  Deployment 

G. 

Life  Cycle  Support 

H. 

Risk  Assessment  and  Management 

I. 

System  and  Program  Management 

Six  of  the  nine  concept  domain  areas  in  Table  1-1  represent  phases  in  the  systems 
engineering  lifecycle: 

A.  Requirements  Definition  and  Management 

B.  Systems  Architecting  and  Conceptual  Design 

C.  Detailed  System  and  Subsystem  Design  and  Implementation 

D.  Systems  and  Interface  Integration 

E.  Validation  and  Verification 

F.  System  Deployment  and  Post  Deployment 

Three  of  the  nine  concept  areas  represent  necessary  process  and  systems  management  support: 

G.  Life  Cycle  Support 

H.  Risk  management 

I.  System  and  Program  Management 

While  other  concepts  could  have  been  identified,  the  Friedman  -Sage  framework 
suggests  these  nine  are  the  most  relevant  to  systems  engineering  in  that  they  cover  the  essential 
life  cycle  processes  in  systems  acquisition  and  systems  management.  Most  other  concept  areas 
that  were  identified  during  the  development  of  the  matrix  appear  to  be  subsets  of  one  of  these. 
The  three  columns  of  this  two-dimensional  framework  represent  the  responsibilities  and 
perspectives  of  government  and  contractor,  and  the  shared  responsibilities  between  the 
government  and  the  contractor.  In  teaching  systems  engineering  in  DoD,  there  has  previously 
been  little  distinction  between  duties  and  responsibilities  of  the  government  and  industry 
activities. 
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1.2  B-2  Friedman-Sage  Matrix 

Table  1-2  shows  the  Friedman-Sage  matrix  for  the  B-2  and  the  areas  in  the  matrix  most 
representative  of  the  five  learning  principles. 


Table  1-2.  Friedman  Sage  Matrix  with  B-2  Learning  Principles  [2] 


Concept  Domain 

Responsibility  Domain 

1.  Contractor 
Responsibility 

2.  Shared 
Responsibility 

3.  Government 
Responsibility 

A. 

Requirements  Definition  and 
Management 

LP  1  Requirement  and 
Design  Integration 

B. 

Systems  Architecting  and 
Conceptual  Design 

LP  3  Reconfiguration 

C. 

System  and  Subsystem  Detailed 
Design  and  Implementation 

LP  4  Subsystem  Maturity 

D. 

Systems  and  Interface  Integration 

E. 

Validation  and  Verification 

F. 

Deployment  and  Post  Deployment 

G. 

Life  Cycle  Support 

H. 

Risk  Assessment  and  Management 

LP  5  Risk  Planning  and 
Management 

I. 

System  and  Program  Management 

LP  2  WBS  Task  Teams 
and  Functional  Hierarchy 

B-2  Learning  Principle  1 .  Integration  of  the  requirements  and  design  processes  is 
represented  by  the  first  row  of  the  concept  domain.  Requirements  Definition  and  Management. 
The  primary  entry  for  this  learning  principle  would  be  the  Shared  Responsibility  because  of  the 
integration  of  the  requirements  team  throughout  the  entire  process,  even  preceding  the 
development  of  the  systems  specification,  and  lasting  for  the  duration  of  the  program.  The 
systems  engineering  process  helps  define  and  manage  the  requirements  and  document  them  in 
the  system  specification.  Other  B-2  vignettes  indicative  of  this  concept  include  the  combined 
team’s  continuous  trade  analysis  during  the  design  process,  the  contractor’s  process  for 
allocating  the  functional  requirements  to  the  design  requirements,  and  the  team’s  ability  to 
develop  alternate  paths  in  the  face  of  high  risk  or  high  cost  requirements. 

The  responsibility  for  the  beginning  of  the  requirements  process  lies  with  the  government 
to  start  the  program  that  fits  within  a  specific  mission  area.  For  the  B-2,  the  DoD  had  already 
developed  a  mission  area  for  strategic  nuclear  strike  and  allocated  bombers  to  the  Strategic  Air 
Command  (SAC),  and  further  stipulated  stealth  as  an  operational  enabler.  However,  the 
capability  of  stealth  as  an  element  of  an  operationally  effective  aircraft  design  was  in  the  early 
development  stages.  The  government  requested  industry  to  assess  possible  solutions  for  this 
mission,  so  the  contractor  shared  in  this  responsibility.  During  the  process,  both  the  government 
and  contractor  personnel  operated  on  the  same  team  to  derive  the  lower  level  requirements  and  to 
assess  the  effect  of  trades  on  the  original  top-level  objectives.  From  the  very  beginning  of 
concept  exploration,  the  responsibility  for  requirements  definition  at  the  operational  and  the 
system  architecture  was  a  shared  responsibility  between  the  contractor  and  the  government  and 
was  a  vital  part  of  the  B-2  program  systems  engineering  process.  Initially  the  government 
specified  a  general  set  of  top-level  performance  objectives  and  the  competing  contractors  were 
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funded  to  pursue  solutions  and  to  further  allocate  the  technical  requirements  in  an  ever- 
increasing  level  of  detail  and  specificity.  This  process  iterated  continually  during  concept 
exploration,  and  eventually  converged  to  a  contract  specification. 

B-2  Learning  Principle  2.  WBS  Task  Teams  and  Functional  Hierarchy  fall  primarily  at 
the  intersection  of  System  and  Program  Management  and  Shared  Responsibility.  While  it  was 
the  government’s  responsibility  to  organize  the  SPO  and  the  contractor’s  responsibility  to  select 
their  own  organizational  structure,  all  parties  agreed  to  organize  consistent  with  the  WBS.  The 
three  major  air  vehicle  company  program  organizations  and  the  SPO  team  became  part  of  the 
WBS  Task  Teams.  In  the  case  of  the  SPO  and  the  prime  contractor,  Northrop,  and  the  two 
primary  subcontractors,  Boeing  and  Vought,  all  were  aligned  functionally,  employed  project 
managers,  and  constructed  teams  consisting  of  multi-discipline  members. 

B-2  Learning  Principle  3.  Air  Vehicle  Reconfiguration  energized  the  team  to  conduct 
trade  studies,  integrate  results,  pursue  alternatives  suggested  by  members  on  the  B-2  team, 
examine  alternative  design  approaches  recommended  by  interfacing  technical  disciplines  and 
WBS  Task  Teams,  and  report  the  progress  to  the  program  technical  and  management  decision 
making  bodies.  This  was  organized,  conducted,  and  implemented  under  the  contractor 
responsibility  for  the  System  Architecture  and  Conceptual  Design. 

B-2  Learning  Principle  4.  Subsystem  Maturity  was  heavily  influenced  by  the  systems 
engineering  process  and  is  again  representative  of  a  Contractor  Responsibility  within  the  System 
and  Subsystem  Detailed  Design  and  Implementation  (third  row,  first  column).  The  contractor 
and  sub-contractor  team  was  responsible  for  the  overall  performance  and  schedule  of 
subsystems.  At  least  a  part  of  the  18  month  schedule  slip  in  first  flight  (from  the  original 
contract  date  of  60  months  after  go-ahead)  may  have  been  avoidable  had  the  reconfiguration 
impact  on  subsystems  immaturity  not  occurred. 

B-2  Learning  Principle  5.  The  Program  employed  Risk  Closure  plans  that  were 
constructed  by  the  WBS  Task  Teams  and  included  all  the  analyses,  tests,  demonstrations,  and 
other  necessary  design  work.  The  work  packages  were  planned  into  the  budget  and  schedule 
tools.  The  entire  task  teams  conducted  these  activities  jointly,  so  this  too,  was  a  shared 
responsibility.  The  importance  of  a  single,  integrated,  jointly  developed,  program  wide  risk 
management  process,  shared  and  understood  by  all,  cannot  be  overemphasized. 

The  Friedman  Sage  matrix  is  used  herein  retrospectively,  as  an  assessment  tool  for  the 
systems  engineering  process  for  the  B-2  program.  Its  use  in  this  case  study  does,  however, 
highlight  the  effectiveness  of  the  concept/matrix  as  an  assessment  tool.  It  should  be  clear  to  the 
student  that  the  application  of  this  tool  to  an  ongoing  program  by  the  systems  engineering  staff 
and  by  the  project/IPT/functional  decision  board  would  provide  insight  and  guidance  for  action. 
This  tool  is  highly  effective  in  organizing  an  assessment  of  the  ongoing  effectiveness  of  the 
systems  engineering  process  because  it  covers  all  aspects  of  a  program.  Additionally,  since  it 
includes  responsibilities  from  both  sides  of  the  program  (customer  and  supplier;  industry  and 
government),  it  is  an  excellent  communication  catalyst  to  assure  understanding  by  both  parties. 
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2.0  SYSTEM  DESCRIPTION 


The  B-2  weapons  system  consists  of  the  B-2  aircraft  and  onboard  systems,  support 
equipment,  training  equipment,  facilities,  and  personnel.  It  includes  all  hardware  and  software  to 
make  it  an  operational  system.  The  deployed  B-2  weapons  system  consists  of  all  of  these 
systems  working  in  an  integrated  manner.  The  systems  engineering  process  is  responsible  for 
the  decomposition  of  requirements,  allocation  of  the  requirements  to  all  levels  of  the  design  and 
to  all  elements,  equipments,  subsystems,  hardware  and  software  of  all  parts  of  the  weapon 
systems,  and  the  verification  that  all  requirements  have  been  satisfied. 

2.1  Mission 

The  B-2  Spirit  is  a  multi-role  bomber  capable  of  delivering  both  conventional  and  nuclear 
munitions.  A  revolutionary  leap  forward  in  technology,  the  bomber  represents  a  fundamental 
shift  in  the  U.S.  bomber  modernization  program.  The  B-2  brings  significant  and  precise 
firepower  to  bear,  in  a  short  time,  anywhere  on  the  globe,  through  previously  impenetrable 
defenses. 

2.2  Features 

The  B-2  provides  the  penetrating  flexibility  and  effectiveness  inherent  in  manned 
bombers.  Low-observables,  or  “stealth,”  characteristics  give  it  the  unique  ability  to  penetrate  an 
enemy’s  most  sophisticated  defenses  and  threaten  its  most  valued,  and  heavily  defended,  targets. 
The  capability  to  penetrate  air  defenses  at  high  altitude  affords  the  platform  efficient  long  range 
cruise  capability  and  holds  even  the  most  distant  targets  at  risk,  provides  an  effective  retaliation 
capability,  an  effective  deterrent,  and  a  formidable  combat  force.  When  coupled  with  the  sister 
bombers,  the  combined  offensive  capability  is  enormous.  The  B-52  provides  significant  payload 
capability  and  long-range  missiles.  The  B-l  has  a  sophisticated  Electronic  Counter  Measures 
(ECM)  suite  and  largely  low  altitude  penetration  routes,  further  diluting  the  defenses  forces. 

The  system’s  low  observability  is  derived  from  a  combination  of  reduced  infrared, 
acoustic,  electromagnetic,  visual,  and  radar  signatures.  The  low  signature  levels  in  these  spectra 
make  it  difficult  for  sophisticated  defensive  systems  to  detect,  track,  and  engage  the  B-2.  Many 
aspects  of  the  low-observability  process  remain  classified;  however,  the  B-2’s  composite 
materials,  special  coatings,  and  flying-wing  design  all  contribute  to  mission  effectiveness. 

The  aircraft  has  a  crew  of  two  pilots,  a  pilot  in  the  left  seat  and  mission  commander  in  the 
right,  compared  to  the  B-lB’s  crew  of  four  and  the  B-52’s  crew  of  five. 

2.3  System  Design 

The  B-2  configuration  was  developed  by  balancing  aircraft  performance  and  survivability 
based  on  the  mission  scenarios  laid  out  by  the  Strategic  Airlift  Command  (SAC)  in  the  late  1970s 
and  refined  in  the  early  1980s.  Views  of  the  aircraft  shown  in  Figure  2-1  show  the  surface 
details  of  the  control  surfaces,  mating  joints,  access  doors,  and  other  interfaces.  Of  interest  is  the 
air  data  system,  shown  as  sets  of  four  small  circles  on  the  top  view  in  front  of  the  cockpit  and  on 
the  bottom  view  engine  bay  doors.  This  air  data  system  has  no  standard  pitot-static  system; 
rather  it  senses  small  changes  in  pressure  and  flow  as  the  angle  of  sideslip  and  attack  change. 
Another  unique  feature,  also  used  in  the  Northrop  B-35  flying  wing  of  the  1940s,  is  the  split,  or 
clamshell  rudders  near  the  tip  of  the  outboard  wing.  These  surfaces  open  on  one  side  at  a  time  in 
response  to  rudder  inputs  to  control  sideslip.  They  can  also  be  opened  simultaneously  to  provide 
a  speed  brake  function.  They  are  augmented  by  asymmetric  thrust  of  the  engines  to  control 


sideslip  during  penetration  mode1.  The  top  view  also  shows  the  refueling  receptacle  aft  of  the 
cockpit  in  the  center,  about  one  third  of  the  way  back. 


Figure  2-1.  External  View  Drawings  of  the  B-2  Aircraft  [1] 


The  company  responsibilities  for  the  design  and  manufacturing  of  the  air  vehicle  are 
shown  in  Figure  2-2.  This  was  decided  early  in  the  program,  prior  to  the  company  proposal. 
The  prime  contractor,  responsible  for  overall  system  design  and  integration,  was  Northrop 
Corporation.  Boeing  Military  Airplanes  Co.,  Hughes  Radar  Systems  Group,  General  Electric 
Aircraft  Engine  Group  and  Vought  Aircraft  Industries,  Inc.  were  key  members  of  the  aircraft 
contractor  team. 


1  Also  noted  in  the  front  view  are  four  auxiliary  intake  doors  protruding  above  the  inlets.  These  doors,  now 
deactivated,  provided  additional  engine  air  flow  during  low  speed  conditions  to  reduce  the  take-off  distance. 
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2.4  Operational  Background 

The  first  B-2  was  publicly  displayed  on  November  22,  1988,  when  it  was  rolled  out  of  the 
Engine  Run  Dock  hangar  at  Air  Force  Plant  42,  Palmdale,  Calif.  Its  first  flight  was  July  17, 

1989.  The  B-2  Combined  Test  Force,  Air  Force  Flight  Test  Center,  Edwards  Air  Force  Base, 
California,  was  responsible  for  flight  testing  the  development  aircraft.  Figure  2-3  shows  the  B-2 
dropping  MK  84  class  weapons  during  testing  and  certification. 


Figure  2-3.  B-2  Dropping  MK  84  Class  Weapons  During  Testing  and  Certification 

Whiteman  AFB,  Missouri,  is  the  only  operational  base  for  the  B-2,  with  21  aircraft  in  the 
active  duty  inventory.  The  first  aircraft.  Spirit  of  Missouri,  was  delivered  December  17,  1993. 
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Depot  maintenance  for  the  B-2  is  performed  at  the  Oklahoma  City  Air  Logistics  Center  at  Tinker 
AFB,  OK 

Figure  2-4  shows  the  B-2  in  a  turn  at  altitude.  Careful  examination  of  the  photograph 
shows  the  split  rudders  are  deflected,  denoting  the  air  vehicle  is  outside  the  maneuver  limits  for 
the  low  observable  penetration  mode.  When  the  aircraft  is  in  penetration  mode,  the  maneuvers 
are  restricted  to  allow  control  of  sideslip  with  differential  thrust  of  the  engines.  When  the 
rudders  split  to  control  sideslip,  it  causes  an  increase  in  radar  cross  section. 


Figure  2-4.  B-2  in  a  turn  at  altitude  [1] 


Table  2-1  lists  the  performance  features  and  weight  of  the  aircraft.  The  weapons  payload 
in  this  table  gives  a  quick  snapshot  of  the  flexibility  of  conventional  and  nuclear  armament.  The 
decision  early  in  the  program  to  retain  the  largest  practical  weapons  bay  size  has  served  the 
growth  capability  of  the  air  vehicle  well,  as  the  length,  height,  and  configuration  of  the  side-by- 
side  weapons  bay  allows  a  wide  range  of  carriage  options.  Additional  weapons  are  planned  for 
certification  as  the  mission  analysis  shows  the  effectiveness  of  other  armaments. 
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Table  2-1.  B-2  Weight  and  Performance  Capabilities  [1] 


Features 

Length 

69  feet 

Height 

17  feet 

Wingspan 

172  feet 

Power  Plant 

4  GE  F-l  18  engines  (17,300  lbs  thrust  each) 

Crew 

Two  pilots 

Weight  Capability 

Max  Takeoff  Weight 

Max  In-flight  Weight 

Max  Landing  Weight 

336.500  pounds 

357.500  pounds 

31 1.500  pounds 

Max  Payload 

44,000  pounds 

Max  Fuel 

166,900  pounds 

Min  Flying  Weight 

Weight  Empty 

161,385  pounds 

149,900  pounds 

Performance  Capability 

Cruise  Performance 

6,000  NM,  unrefueled  at  high  altitude 

Airport  Performance 

Takeoff,  Std  day,  Sea  Level 
Landing,  240,000  pounds 

8,000  feet  at  maximum  takeoff  weight 

5,000  feet 

Speed 

High  subsonic 

Ceiling 

50,000  feet 

Payload 

40,000  pounds 

Weapons  Payload 

Nuclear  Payload 

16B-83 

16  B-61-7 

8  B-61-1 1 

Conventional  Payload 

16  GBU-31  (JD AM-84) 

80  GBU-38  (JD AM-82) 

16  AGM-154A  (JSOW-97) 

The  combat  effectiveness  of  the  B-2  was  proven  in  Operation  Allied  Force,  where  it  was 
responsible  for  destroying  33  percent  of  all  Serbian  targets  in  the  first  eight  weeks,  after  flying 
nonstop  to  the  Balkans  from  its  home  base  in  Missouri  and  back.  In  support  of  Operation 
Enduring  Freedom,  the  B-2  flew  one  of  its  longest  missions  to  date  from  Whiteman  to 
Afghanistan  and  to  Diego  Garcia,  changed  crew,  and  flew  back.  The  B-2  completed  its  first-ever 
combat  deployment  in  support  of  Operation  Iraqi  Freedom,  flying  22  sorties  from  a  forward 
operating  location  as  well  as  27  sorties  from  Whiteman  AFB  and  releasing  more  than  1.5  million 
pounds  of  munitions.  The  B-2  has  been  at  full  operational  capability  (FOC)  since  December 


2003. 
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3.0  B-2  PROGRAM  EXECUTION 


This  section  will  follow  the  execution  of  the  B-2  program  from  the  inception  of  an  idea  in 
1978  to  the  first  flight  on  July  17,  1989.  The  discussion  will  introduce  the  transition  to 
production  and  operational  activation,  but  the  concentration  of  the  case  is  on  the  application  of 
the  systems  engineering  process  from  the  early  days  to  the  first  flight. 

Table  3-1  shows  the  milestones  for  the  program.  The  learning  principles,  LP1  through 
LP5  noted  in  the  Table,  indicate  the  dates  when  they  first  surfaced.  This  Table  should  be  a 
handy  reference  to  the  reader  to  keep  dates  and  events  in  the  proper  chronological  context. 


Table  3-1.  B-2  Events/Milestones 


Event 

Date 

Concept  Exploration 

Vietnam  War 

1965-1972 

Technology  investigations 

1970-1976 

Computer  model  development 

1966-1970 

DARPA  Studies 

1974-1978 

XST  Phase  1 

June  1975 -April  1976 

Have  Blue,  XST  Phase  2 

April  1976- June  1979 

Tacit  Blue 

1978-1985 

F-117 

Nov  1978  go  ahead 

ASPA  studies 

1978-1981 

RFP  release 

Sep  1980  (LP1) 

Source  Selection 

30  Nov  1980-30  Nov  1981  (LP2,  LP5) 

Low  altitude  Modification  Request 

April  1981 

Third  Crew  Member  MR 

April  1981 

Full  Scale  Engineering  Development 

Contract  award 

Dec  1981 

Initial  Full  Scale  Engineering  Develop 

Dec  1981-Jun  1983 

PDR  1 

Oct  1982 

Reconfiguration 

Feb  1983-Aug  1983  (LP3,  LP4) 

Configuration  Freeze 

July  1983 

PDR  2 

Mar- April  1984 

CDR 

Dec  1986 

First  Flight 

17  Jul  1989 

Delivery 

First  Delivery  to  ACC 

17  Dec  1993 

Full  operational  capability 

Dec  2003 

3.1  Concept  Exploration 

The  Concept  Exploration  phase  of  the  B-2  program  started  officially  when  the  Advanced 
Strategic  Penetrating  Aircraft  (ASPA)  studies  were  conducted,  which  was  preceded  by  several 
early  stealth  programs.  This  phase  included  the  definition  of  needs  by  the  Strategic  Air 
Command  (SAC)  and  the  derivation  of  the  system  requirements  for  the  Full  Scale  Engineering 
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Development  contract.  It  also  balanced  the  desires  of  the  user  between  technology  risk  and 
capability. 

3.1.1  Early  Stealth  Programs 

The  concept  of  stealth  technology  intrigued  aircraft  designers  from  the  beginning  of  the 
invention  of  radar.  Engineers  and  scientists  investigated  various  techniques  to  avoid  detection 
dating  to  the  1940s.  Designs  to  reduce  noise  even  preceded  these  efforts.  By  the  mid-1960s,  the 
Air  Force  Avionics  Laboratory  at  Wright  Patterson  Air  Force  Base,  Ohio  had  funded  studies  to 
develop  radar  cross-section  prediction  computer  programs,  camouflage  techniques,  models, 
materials  and  concepts  [5].  Studies  of  radar  absorbing  materials  (RAM)  and  shaping  techniques 
were  also  funded  and  had  yielded  a  concept  called  “iron  paint”,  a  technique  to  embed  ferrite 
particles  in  a  quarter  inch  thick  flexible  rubberized  film.  In  the  early  1970s,  research  had 
continued  into  methodologies  to  control  the  physical  scattering  of  sensor  outputs  for 
representative  aircraft  shapes.  Northrop  had  successfully  developed  a  radar  cross-section  (RCS) 
prediction  code  called  GEMSCAT  and  had  successfully  predicted  the  radar  cross-section  of  the 
F-4.  Teledyne  Ryan  had  experimented  and  flown  low  radar  cross-section  drones  and  had 
developed  analytical  techniques  for  the  design  of  leading-edge  RAM. 

The  early  work  by  both  the  government  and  industry  during  this  timeframe  resulted  in 
proving  low  observables  could  successfully  be  applied  to  aircraft,  ships,  and  other  vehicles.  The 
current  inventory  of  stealth  platforms  throughout  the  military  can  all  trace  their  roots  to  these 
early  technology  maturation  programs  and  the  initial  prototype  aircraft  developed  throughout  the 
1970s. 

The  experience  in  Vietnam  showed  Air  Force  planners  the  emerging  trend  of  the 
expanding  threat  from  radar  detection  and  radar  guided  missiles.  This  trend  was  forcing  a 
change  in  tactics  to  assure  aircraft  survivability.  F-4  Wild  Weasels  were  used  to  encourage  the 
radars  to  try  to  illuminate  them  so  the  Weasel  crews  could  try  to  destroy  the  radars.  The  constant 
threat  of  the  more  sophisticated  and  extremely  capable  radar/missile  complexes  became  a 
priority  in  mission  planning.  However,  it  was  the  Yom  Kipper  War  in  Oct  1973  that  provided 
the  catalyst  needed  to  bring  the  emerging  stealth  technology  into  the  forefront  of  interest  and  to 
finally  provide  the  impetus  that  would  result  in  their  emergence  as  operational  systems.  The 
vulnerability  of  U.S.  aircraft  to  the  new  and  expanding  Soviet  air-to-air  and  surface-to-air 
missiles  and  their  companion  radar  was  a  disturbing  fact  of  life.  Many  of  the  frontline  Israeli 
fighter  aircraft  shot  down  in  the  Yom  Kipper  War  were  the  frontline  aircraft  of  their  Allies. 

They  were  falling  victim  to  the  front  line  Soviet  radars  at  an  alanning  rate.  In  1974,  the  Defense 
Advanced  Research  Projects  Agency  (DARPA)  initiated  studies  to  determine  radar  cross-section 
levels  required  to  defeat  the  Soviet  threats  and  various  ways  these  levels  may  be  achieved. 
Northrop  and  McDonnell  Douglas  received  contracts  for  this  work.  Lockheed  was  soon  added  to 
the  list.2  DARPA  initiated  the  Experimental  Survivability  Testbed  (XST)  program  in  the 
summer  of  1975  to  conduct  aircraft  systems  analysis  on  low  RCS  vehicles  and  to  conduct  radar 
cross-section  testing  of  representative  configurations  and  components.  Northrop  and  Lockheed 
both  received  a  Phase  1  contract  to  test  models  of  their  concepts  mounted  on  a  pole  at  the 


“An  excellent  summary  of  the  early  works  in  low  observables,  along  with  the  details  of  Have  Blue  and  the 
F-l  17A  can  be  found  in  Reference  4. 
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government  RCS  test  range  at  White  Sands  Missile  Range,  NM.  Lockheed  was  selected  as  the 
winner  for  Phase  2  in  a  close  competition  in  April  1976  and  flew  the  first  Have  Blue  aircraft 
December  1,  1977  .  Figure  3-1  shows  both  the  Lockheed  and  the  Northrop  XST  proposal 
configurations.  _ 


0  O 

Figure  3-1.  Lockheed  Have  Blue  (left)  and  Northrop  (right)  XST  Aircraft  [5]. 

Northrop  was  encouraged  by  the  Air  Force  and  DARPA  to  continue  their  stealth 
technology  efforts  following  the  loss  of  the  XST  competition.  Northrop  continued  research  on 
new  techniques  to  reduce  RCS  and  predictive  code  development  using  IRAD  funding  and 
funding  from  DARPA.  Their  promising  efforts  resulted  in  the  award  of  a  contract  to  develop  a 
low  observable  reconnaissance  aircraft  with  a  new  radar  concept  offered  by  Hughes  called  Low 
Probability  of  Intercept  (LPI).  This  program  resulted  in  the  Tacit  Blue  aircraft3 4  which  first  flew 
in  February  1982  and  would  complete  139  flights  over  the  next  four  years.  Most  importantly, 
this  aircraft  became  the  radar  cross-section  demonstration  vehicle  that  validated  the  design 
approach  for  the  B-2.  This  aircraft  played  a  significant  role  in  the  maturation  of  stealth 
technology,  prediction  codes,  edge  RAM,  shaping  (controlled  curvature  as  opposed  to  flat  sided 
shaping  per  the  XST),  engine  inlet  integration,  coatings,  and  the  tailoring  of  the  RCS  pattern,  all 
of  which  were  vital  to  the  development  of  the  B-2.  The  development  program  gave  Northrop  the 
experience  and  validated  these  vital  aircraft  details.  The  Tacit  Blue  aircraft  is  shown  in 
Figure  3-2. 

3.1.2  Advanced  Strategic  Penetrating  Aircraft  (ASP A) 

The  genesis  of  the  Northrop  B-2  stealth  bomber  program  was  a  funded  study  initiated  by 
the  Air  Force  in  January  1980  to  examine  the  feasibility  of  developing  a  long-range  strategic 
bomber  employing  low  observables  or  stealth  features.  This  aircraft  study  was  named  Advanced 
Strategic  Penetrating  Aircraft,  ASPA5.  Low  observables  had  proven  it  was  a  practical 


3  Both  Have  Blue  aircraft  were  lost  in  flight  test  accidents,  the  causes  unrelated  to  stealth  technology. 

4The  aircraft  is  in  the  National  Museum  of  the  Air  Force  in  Dayton  Ohio. 

5  The  aircraft  was  later  officially  named  the  Advanced  Technology  Bomber,  ATB,  by  the  end  of  the  source 
selection.  It  was  officially  named  the  B-2  in  September  1984. 
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technology  during  flight- tests  of  the  Have  Blue  aircraft  from  December  1977  to  July  1979.  The 
development  of  the  stealth  fighter,  the  F-l  17  full  scale  development  contract  had  been  awarded 
to  Lockheed  Skunk  Works  in  Burbank,  California  in  November  1978,  so  the  concept  for 
operational  deployment  of  stealth  aircraft  was  evolving  and  maturing  in  the  Tactical  Air 
Command. 


Figure  3-2.  Northrop  Tacit  Blue  [5]. 

The  Strategic  Air  Command  had  taken  notice  of  the  potential  opportunities  afforded  by 
stealth  and  the  Plans  Division  initiated  internal  studies  on  the  value  of  stealth  to  penetrate  the 
extensive  Soviet  defensive  radar  suite  in  early  1978.  SAC  was  particularly  interested  in  the  new 
technology  as  it  may  be  applied  to  a  new  penetrating  platform  because  President  Jimmy  Carter 
had  cancelled  the  B-1A  program  in  June  1977.  This  situation  left  the  User  faced  with  continuing 
their  mission  with  the  conventional  and  older  B-52  and  the  FB-1 1 1. 

3.1.3  ASPA  Study  Contracts 

Northrop  was  approached  by  Lt.  Gen.  Stafford,  USAF/RD,  in  the  second  quarter  of  1979 
and  asked  to  study  the  application  of  their  approach  to  the  low  observables  technology  to  the 
ASPA6.  Their  approach  to  LO  used  smooth  contoured  shaping  of  the  exterior  surface,  as 
opposed  to  flat-sided  panels,  as  characterized  by  Lockheed’s  F-l  17.  Once  Northrop  committed 
to  conduct  a  company-funded  study  in  mid  1979,  USAF/RDQ  and  SAC  provided  a  limited 
number  of  experienced,  on-site/on-call  representatives  to  provide  functional  and  performance 
requirements  guidance  as  Northrop  examined  various  performance  and  planform  alternatives  for 
performing  the  strategic  missions. 

The  LO  technology  knowledge  base  imposed  constraints  on  the  capabilities  that  could  be 
examined  for  the  ASPA  -  i.e.  design  of  a  LO  treated  supersonic  inlet  was  beyond  the  state-of- 
the-art.  Northrop’s  efforts  soon  began  to  focus  on  the  feasibility  of  integrating  a  very 
aerodynamically  efficient  (high  Lift/Drag  ratio)  and  LO  compatible  planform  -  the  flying  wing. 
This  was  compared  to  a  subsonic  low  altitude  penetrator  to  glean  the  benefits  of  the  competing 
approaches.  Sufficient  progress  was  made  the  rest  of  the  year  to  induce  the  USAF  to  award 
Northrop  a  concept  study  and  demonstration  contract  in  January  1980.  The  contract  called  for 


6  Lockheed  was  already  working  under  an  Air  Force  contract  to  study  a  penetrating  bomber  feasibility  for 
their  faceted  conceptual  approach  to  low  observables 
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wind  tunnel  model  tests  of  the  aerodynamic  configuration  and  large-scale  RCS  model  tests  of  the 
same  external  mold  lines,  in  addition  to  continuing  the  development  of  the  aircraft  and  weapon 
system  conceptual  designs. 

Once  Northrop  had  agreed  to  study  the  ASPA  in  the  late  spring  of  1979,  the  Systems 
Analysis  group  within  Northrop  Advanced  Projects  formulated  a  matrix  of  analyses,  each 
addressing  a  feature  of  the  long  range  penetration  bomber  effectiveness.  The  independent 
variables  were  engineering  parameters  of  systems  and,  in  some  cases,  subsystem  design.  This 
analysis  technique  had  generally  been  known  as  “Measures  of  Effectiveness”  (MOE).  Advanced 
Projects  had  started  constructing  MOE  analysis  models  as  early  as  1976  during  Northrop’s 
participation  in  the  XST  program  and  continued  refining  and  expanding  its  models  during  the 
conceptual  and  preliminary  design  phases  of  Tacit  Blue.  Central  to  this  capability  was  a  very 
simple  generic,  all-aspect,  multi-frequency  RCS  description  that  was  empirically  based  on  the 
knowledge  accumulated  by  AP’s  RCS  engineers  from  the  thousands  of  experimental  tests  on  the 
radar  range.  This  model  construct  was  so  flexible  that  it  could  be  used  to  help  the  designers  to 
synthesize  aircraft  configuration.  All  prior  RCS  models  were  far  to  complex  and  were  only 
useful  for  analysis  of  already  created  configurations. 

The  ASPA  studied  the  same  objectives  of  all  intercontinental  strategic  bombers,  namely 
6,000  mn  range  unrefueled  and  10,000  pounds  of  payload.  The  attractiveness  of  stealth  to 
enhance  survivability  gave  the  edge  to  the  ASPA  platforms  over  then  conventional  approaches, 
although  all  previous  approaches  were  considered,  including  ECM.  By  appreciating  that  a  wide 
variety  of  aircraft  and  configurations  can  be  made  to  fly  adequately  with  sufficient  thrust  and  fly- 
by-wire  stability  augmentation,  an  aircraft’s  wings-level  best  case  range  payload  features  can  be 
estimated  with  just  a  two  dimensional  planform  representation. 

The  MOE  addressed  as  dependent  variables  a  number  of  mission  parameters  such  as 
range,  penetration  altitude,  and,  most  importantly,  the  elements  of  what  constitutes  survivability, 
such  as  detection  range,  time-in-track,  firing  opportunity  time,  etc.  Without  a  preconceived 
notion  of  what  the  weapon  system  would  physically  look  like,  engineering  parameters,  such  as 
leading/trailing  sweep,  inlet/exhaust  location,  etc.,  were  traded  off  as  independent  variables. 
Features  of  the  three  basic  aircraft  types,  wing-body-tail,  flying  wing,  and  blended-wing-body 
(delta)  were  studied  because  the  MOE  analysis  was  made  as  deterministic  and  transparent  as 
possible,  widespread  confidence  in  the  engineering  tradeoffs  was  easily  achieved.  In  less  than 
two  months  of  study  addressing  worst  case  air  defense  scenarios  projected  20  years  to  the  future, 
the  most  effective  RCS  features  became  obvious.  Significantly,  the  analysis  showed  it  was 
possible  to  configure  the  bomber  for  survivable  penetration  (of  air  defenses)  at  high  altitude.  A 
less  stressing  low  altitude  penetration  would  be  even  more  survivable,  albeit  with  a  less  efficient 
aircraft  [3,  Griskey]. 

The  effort  during  this  period  was  focused  on  system  engineering  studies  of  the  weapon 
system,  air  vehicle,  avionics,  and  armament  systems;  conceptual  design  and  trade  studies  of  the 
airframe  structure  and  subsystems  concepts;  development  testing  of  large  and  small  scale  LO  and 
aerodynamic  models  and  representative  structures;  and  the  conceptual  construct  of 
manufacturing  and  logistics  support  plans.  The  presence  of  the  SAC  and  RDQ  representatives 
greatly  facilitated  these  efforts,  because  Northrop  did  not  have  a  large  knowledge  base  of  SAC 
operations  and  the  SIOP  missions. 
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By  mid-year  (1980),  USAF  had  seen  sufficient  progress  by  both  contractors  that  they 
instructed  Aeronautical  Systems  Division  (ASD)  to  prepare  a  request  for  proposal  (RFP)  for 
Full-Scale  Engineering  Development  (FSED)  of  the  Advanced  Technology  Bomber  (ATB)  [3, 
Glenn].  The  contractors  began  to  augment  their  staffs  to  respond  to  the  RFP.  Both  Lockheed 
and  Northrop  elected  to  compliment  their  resources  with  out-of-company  assistance  for  the 
program.  Lockheed  selected  Rockwell  as  a  partner  in  1978,  notwithstanding  they  were  not 
currently  pursuing  any  stealth  programs  with  the  Air  Force  or  DARPA  and  were  the  obvious 
choice  to  build  the  B-1B  if  Ronald  Reagan  won  the  election  over  incumbent  President  Carter. 
Northrop  selected  Boeing  and  Vought  as  “teammates,”  notwithstanding  their  inexperience  in  low 
observables,  and  Boeing’s  reluctance  to  accept  a  contractual  relationship  as  a  subcontractor. 

Throughout  1980,  the  program  evolved  rapidly  from  a  Concept  Study  to  a  full-blown 
design  and  proposal  effort  on  the  Advanced  Technology  Bomber  (ATB).  It  was  the  efforts  of  the 
government  and  industry  during  the  time  frame  of  1979,  through  1980,  and  ending  in  the 
summer  of  1981,  that  the  requirements  for  the  B-2  were  derived,  traded  and  balanced,  approved, 
and  documented.  This  early  study  effort,  the  RFP  preparation  by  the  government,  the  FSED 
proposal  response  prepared  by  Northrop  and  Lockheed,  and  the  subsequent  source  selection  and 
contract  negotiation  were  the  key  events  during  this  crucial  time  for  the  program. 

During  the  Study  Phase,  industry  and  government  team  staffing  was  minimal.  The 
program  management  on  the  government  and  industry  sides  was  able  to  convince  their  respective 

headquarters  that  the  most  experienced  and 
technology-oriented  personnel  should  be 
assigned  to  the  preliminary  design  effort  on  a 
full-time  basis.  Northrop  assigned  Jim  Kinnu 
from  the  Aircraft  Division  to  be  the  program 
manager,  Irv  Waaland  from  Advanced  Design 
as  the  Chief  Engineer,  John  Cashen  from 
Advanced  Technology  as  the  lead  technologist 
and  George  Friedman,  Vice  President  for 
Engineering  from  Northrop ’s  Electronic 
Systems  Group  (ESG)  to  lead  the  avionics 
architecture  derivation.  See 

Although  there  was  no  formal  system 
engineering  organization  or  construct  in  the 
study,  the  system  architecture  and  preliminary  design  were  accomplished  using  the  systemic 
skills  of  the  highly  experienced  team  members.  The  small  size  of  the  group,  coupled  with  their 
experience  and  their  “systems  thinking”  attitude,  examined  the  trade  space  available  to  low 
observables,  including  high  and  low  altitude  and  from  low  subsonic  to  high  subsonic  speeds. 

This  led  to  the  eventual  selection  of  a  preliminary  conceptual  design  and  architecture  which 
balanced  aircraft  performance  requirements  with  emerging  technology  and  innovative  design. 
Some  of  this  data  is  captured  in  Appendix  4.  Crucial  to  this  rapid  convergence  was  the 
participation  by  Air  Force  management  and  technical  personnel,  increasing  the  speed  and 
communication  between  government  and  contractor  with  a  spirit  of  cooperation  that  has  not  been 
observed  either  before  or  after  the  B-2  program  [3,  Friedman,  et.  al]. 

Despite  the  lack  of  formal  organization  and  processes,  the  systems  engineering  methods 
employed  by  the  team  would  have  been  acceptable  in  today’s  manuals  [3,  Friedman]  on  how 


Figure  3-3.  Shown  are  Irv  Waaland 
(left),  Steve  Smith,  Aircraft  Division  Vice 
President  and  John  Cashen  (right) 
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systems  engineering  should  be  conducted  in  the  early  phases:  focus  on  mission  requirements  and 
campaign  models  -  augmented  by  many  in-depth  discussions  with  operational  personnel, 
functional  flow  diagrams,  requirements  flow  down  and  trade  studies.  Communications  were 
accomplished  by  a  “sea  of  thousands  of  viewgraphs”,  with  the  decisions  of  each  meeting 
compactly  captured  by  a  page  or  two  of  memos,  signed  by  the  stakeholders  of  that  part  of  design. 
Several  rooms  with  sheet  metal  walls  were  devoted  to  the  building  of  the  many  presentations 
always  in  process,  with  a  complex  “configuration  management”  control  on  the  status  of  approval 
of  each  slide. 

It  was  during  the  study  phase  that  the  fundamental  architecture  of  the  B-2  avionics 
system  was  derived.  The  major  architectural  decisions  were  in  the  areas  of  the  radar,  navigation, 
crew  station,  computer,  software,  and  data  bus.  Three  primary  objectives  were  established  for 
the  design  trades:  in  order  of  priority  [3,  Wheelock]: 

1 .  Survivability 

2.  Effectiveness 

3.  Range/payload  and  Lift/  Drag  (L/D) 

Survivability’s  components  included  reaction  time,  takeoff  distance,  observables,  system 
hardness,  altitude,  speed  and  active  defense.  Effectiveness’s  components  included  range, 
navigational  accuracy,  target  acquisition,  bomb  damage  assessment,  reliability,  payload,  weapon 
accuracy,  and  speed.  Weight  has  long  been,  and  continues  to  be,  a  driving  system  requirement. 

It  is  useful  as  a  cost  estimation  relationship,  but  also  drove  the  B-2  high  altitude  capability  and 
range. 

The  navigation  subsystem  trade  off  for  reliability  indicated  the  need  for  redundant 
navigation  subsystems.  Other  long-range  bombers  had  two  inertial  navigators  initialized  by  a 
period  of  gyro  compassing  and  radar  fixes  during  climb  out,  requiring  updates  by  additional 
radar  fixes  at  intervals  along  the  route.  Reaction  time  was  a  critical  issue  regarding  initial  air 
strikes  against  our  bases;  thus  the  bomber  needed  a  navigation  system  that  could  be  operational 
within  the  timeline  of  other  startup  functions.  Also  survivability  concerns  dictated  minimum 
emissions  for  navigational  updates,  especially  at  high  altitudes  above  enemy  airspace.  Other 
navigational  considerations  included  the  need  to  deliver  gravity  weapons  with  high  precision 
after  long  periods  over  water  where  updates  were  not  available.  The  derived  architecture 
identified  an  astrotracker  with  dual  inertial  platfonns  along  with  Low  Probability  of  Intercept 
(LPI)  radar  updates7. 

Radar  subsystem  decisions  were  also  made  early  on  that  had  far  reaching  implications. 
Although  the  primary  mission  was  strategic  nuclear  strike,  careful  consideration  was  given  to  the 
likelihood  of  tactical,  conventional  weapon  delivery.  Tradeoffs  were  made,  especially  in  the  area 
of  the  radar  resolution,  where  studies  were  made  regarding  the  benefits  of  higher  resolution: 
higher  navigational  accuracy,  superior  ability  to  acquire  a  wide  range  of  target  classes  and  to 
perform  bomb  damage  assessment,  pattern  recognition  and  the  ability  to  deliver  weapons  more 
accurately  in  a  “relative  guidance  system”  manner. 


7  While  the  system  currently  has  GPS,  it  was  not  initially  available  but  full  provisions  were  incorporated  as 
part  of  the  FSED  contract. 
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Myriads  of  technical  decisions  were  made  for  the  aircraft  and  the  avionics  subsystems. 

All  were  approached  by  an  architectural  flow-down  to  successively  provide  a  more  precise 
definition  for  the  approach  to  achieving  the  best  blend  of  aircraft,  avionics,  and  stealth 
characteristics  in  an  operationally  useful,  survivable  weapons  system  that  would  stand  the  test  of 
time  in  a  wide  range  of  conflicts.  See  Appendix  4  for  portions  of  this  final  out-briefing  of  the 
Northrop  study  to  Lt  Gen  Stafford.  The  study  effort  by  the  contractors  formed  the  basis  for  the 
preparation  of  their  responses  to  the  ATB  Request  for  Proposal,  released  by  the  Air  Force  on  1 
September  1980  to  Northrop  and  Lockheed. 

3.1.4  Source  Selection 

The  source  selection  and  evaluation  of  proposals  was  accomplished  in  a  unique  manner. 
The  proposals  were  evaluated  at  the  contractor’s  facilities  using  a  team  of  highly  qualified 
experts  assembled  from  across  Air  Force.  The  team  consisted  of  60  evaluators,  of  which  35  were 
engineers  from  Wright  Patterson  Air  Force  Base,  OH.  These  engineers  were  handpicked  from 
all  the  programs  in  development  at  WPAFB  and  represented  the  technical  leader  in  each 
functional  area.  The  people  were  assigned  to  the  source  selection  team  until  the  source  selection 
was  finished  (estimated  as  2-3  months  full  time,  then  as-needed  until  contract  award),  after 
which  time  they  would  return  to  their  initially  assigned  programs.  Because  these  people  were 
working  the  most  important  projects  in  the  Air  force  and  held  key  positions,  this  decision  showed 
an  early  and  significant  commitment  by  the  leadership  of  the  Air  Force. 

3.1.5  Development  of  the  Weapons  System  Specifications 

When  the  source  selection  started  on  November  30  1980,  the  government  Source 
Selection  Evaluation  Board  (SSEB)  team,  chaired  by  Col  Joseph  K.  Glenn,  traveled  to  the 
contractors’  facilities  to  conduct  the  evaluation.  The  contractors  each  provided  the  SSEB  with 
secure  office  space,  isolated  from  the  contractor’s  team,  but  in  close  proximity.  Accomplishing  a 
source  selection  at  the  contractor’s  location  was  an  unprecedented  approach  for  large  weapons 
system  procurement  and  it  turned  out  to  have  a  very  positive  benefit.  It  further  cemented  the 
close  working  relationship  between  the  Air  Force  and  the  prime  contractor  that  had  started  in  the 
initial  study  phase  and  it  assisted  markedly  in  requirements  development. 

The  general  ASPA  system  requirements  in  the  RFP  were  derived  from  the  results  of  the  company  studies  that 
started  in  1979  and  were  underway  in  1980  when  the  RFP  was  prepared.  Each  contractor  had  assembled 
design  teams  and  performed  many  system  engineering  analyses  and  trade  studies  to  define  and  refine  their 
initial  system  conceptual  approach.  The  requirements,  however,  had  not  been  fully  discussed  with  the 
government  evaluation  team,  as  most  of  the  members  were  new  to  the  program,  having  recently  been  briefed 
on  the  existence  of  the  program.  The  iteration  process  of  the  requirements  and  the  design  occurred  over  the 
first  six  months  of  the  evaluation  of  the  proposals  and  was  conducted  jointly  by  both  the  Air  Force 
requirements  team  and  the  contractor’s  design  team. 

Table  3-2  shows  the  key  RFP  requirements,  the  contractor’s  proposed  value,  and  the 
value  as  included  in  the  specification. 

Lockheed  and  Northrop  used  their  resultant  conceptual  designs  from  the  study  contracts 
as  their  preferred  approach  to  prepare  their  responses  to  the  RFP.  Each  had  conducted  many 
trade  offs  between  classic  aircraft  performance  characteristics  (figures  of  merit)  and  levels  of  low 
observables  (radar  cross  section,  infrared  emissions,  visual,  acoustic,  and  radio  frequency 
emissions).  Subsystem  design  approaches  were  evaluated  against  the  general  requirements  for 
the  study  to  select  the  best  internal  equipment  and  their  arrangement.  The  derived  design  from 
Northrop  was  a  very  aerodynamically  efficient,  high  altitude  cruise  design  with  a  balance  of 
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good  aircraft  performance  and  low  observables  levels.  The  primary  role  of  the  ASPA  was  for 
long  range,  high  altitude  cruise  penetration  of  the  Soviet  radar  network.  There  were  14  missions 
stipulated  in  an  appendix  for  calculation  of  range,  payload,  PSR,  structural  durability  design 
spectrums,  and  anything  requiring  an  operational  mission  for  events,  weapons,  environments, 
and  penetration  corridors.  The  proposed  system  concept  was  designed  for  HI-HI-HI-HI 
missions,  such  as  the  one  in  Figure  3-4,  which  is  duplicated  from  the  original  1980  study.  It  is 
shown  here  for  illustration  of  a  typical  HI-HI-HI-HI  mission. 


Table  3-2.  RFP  and  Specification  Requirements 


Document 

RFP 

Proposal 

Specification 

Range  nautical  miles 

6,000 

8,500 

6,000 

Payload  lbs 

40,000 

40,000 

40,000 

Low  altitude 

alt  above  terrain 
Mach 

Residual 

Capacity 

400’  w/o  TF 

0.6M 

200’  w /  TF 

0.7M 

High  altitude 

Cruise  altitude 
Cruise  Mach 

>35,000  ft 
>0.8M 

>50,000  ft 
>0.8M 

50,000  ft  max 
>0.8M 

PSR 

0.90 

0.90 

0.90 

Wing  span 

— 

172  ft 

— 

Gross  weight 

— 

269,000  lbs 

— 

Lesend 

TF  =  Terrain  Following 

PSR  =  Primary  System  Reliability 

There  was  also  a  mission  for  HI-LO-LO-HI  operation  stipulated  in  the  original  RFP,  but 
this  was  a  fallout  capability,  not  a  specific  design  point.  See  Figure  3-5,  again  duplicated  from 
the  original  1980  study,  and  shown  with  the  low  altitude  concept  as  illustrative  of  a  HI-HI-LO- 
LO  mission.  The  low  altitude  mission  in  the  original  RFP  did  not  stipulate  the  maximum  speed 
or  terrain  following  altitude  capability.  It  should  be  noted  that  because  this  was  neither  a 
specified  design  point  nor  a  primary  mission,  the  contractors’  high-altitude  design  would  not 
have  added  additional  functionality  to  address  a  low  altitude/  high  speed  operation. 

A  large  scale  radar  cross-section  (RCS)  pole  model  of  each  contractor’s  conceptual 
design  was  initially  built  and  tested  at  the  RASCAT  facility,  White  Sands,  NM  as  part  of  the 
Study  Contracts.  Both  contractors  modified  their  models  and  retested  them  during  the 
evaluation.  The  data  formed  the  basis  of  the  RCS  trade  studies,  the  preliminary  RCS 
specification,  and  the  survivability  assessment  by  the  SSEB  during  the  evaluation  period. 

Each  contractor  had  prepared  specifications,  a  Work  Breakdown  Structure  (WBS),  the 
contract  Statement  of  Work  (SOW),  and  model  contract  as  part  of  their  proposal  submittal. 
When  developing  the  specifications,  each  contractor  documented  its  design  approach  in  a  very 
descriptive  Part  II  specification  fonnat.  These  specifications,  however,  were  far  more 
descriptive  than  desired  by  the  Air  Force.  The  government  desired  only  a  performance-based 
Part  I  type  specification  for  the  contract,  with  the  eventual  Part  II  specifications  to  be  developed 
during  the  conduct  of  the  program  by  the  selected  contractor. 
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Figure  3-4.  Typical  HI-HI-HI-HI  Mission  from  1980  DARPA  Study. 


Figure  3-5.  Typical  HI-HI-LO-LO  Mission  from  1980  DARPA  Study 

The  government  team  immediately  started  to  prepare  a  complete  set  of  performance- 
based  specifications  for  the  entire  system  (Weapons  System,  Air  Vehicle  and  Engine 
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specifications).  Concurrently,  they  were  conducting  the  evaluation  of  the  proposals.  Since  each 
of  the  members  of  SSEB  was  handpicked  for  their  expertise  and  was  well  experienced  in  the 
development  of  specifications,  they  were  all  given  the  latitude  to  leave  the  government 
evaluation  area  and  speak  directly  with  the  contractor’s  engineer  in  their  technical  discipline. 

This  dialog  created  an  understanding  by  the  evaluator  of  the  implication  of  their  proposed 
performance  requirements  on  the  difficulty  to  design  and  integrate  its  subsystem.  It  also  gave  the 
designer  a  detailed  understanding  of  the  objective  of  the  requirements.  This  communication 
generated  an  outstanding  understanding  by  both  parties  of  the  implications  of  each  requirement 
and  the  difficulty  of  the  design  to  achieve  them. 

If  an  evaluator  did  not  understand  why  the  contractor  engineer  had  chosen  a  particular 
path,  or  the  evaluator  thought  there  might  be  a  better  approach,  the  evaluator  was  allowed  to  talk 
directly  to  the  contractor  engineer  at  their  desk.  They  would  discuss  the  mission,  the  design 
approach  for  the  technical  discipline,  and  develop  an  understanding  of  what  they  both  thought 
was  best  for  the  overall  system.  Following  the  dialog,  the  government  evaluator  would  construct 
proposed  specification  language  and  present  the  proposed  requirements  wording  to  the 
specification  board  for  incorporation  into  the  government  performance-based  specifications.  If 
the  proposed  approach  and  the  requirement  wording  could  be  defended  before  the  board,  it  was 
incorporated.  It  was  common  for  several  iterations  to  occur  between  the  technical  area  specialist, 
iterating  the  wording  with  the  contractor  counterpart  and  the  specification  board  before  the  final 
language  was  adopted.  Only  the  government  personnel  attended  the  specification  board  meeting. 
Northrop  also  had  an  infonnal  board  that  examined  and  ruled  on  all  of  the  Contractor  Inquiries 
(CIs),  Deficiency  Reports  (DRs),  and  Modification  Requests  (MRs)  sent  in  by  the  government 
evaluators,  most  of  which  had  been  prepared  with  the  help  of  the  contractor  counterparts.  All 
specification  changes  were  processed  by  MRs. 

Another  significant  event  occurred  during  the  source  selection,  this  one  regarding  the 
engine.  The  RFP  stipulated  the  engine  would  be  Contractor  Furnished  Equipment  and  the 
contractors  bid  accordingly.  During  the  source  selection,  the  SSEB  [3,  Abell]  recommended  to 
the  SSAC  (chaired  by  Gen  Lawrence  T.  Skantze,  with  membership  of  Maj  Gen  James  “Abe” 
Abramson,  and  Maj  Gen  Monroe  T.  Smith)  that  the  engine  should  be  a  separate  contract, 
managed  by  the  SPO  with  support  from  the  Engine  SPO  at  WPAFB  and  the  suggestion  was 
approved.  The  engine  was  selected  as  Government  Furnished  Equipment  and  a  separate  source 
selection  was  conducted.  General  Electric  was  eventually  selected  over  Pratt  and  Whitney. 

3,1.6  Development  of  the  Low  Observable  (Stealth)  Requirements 

Specifying  the  requirements  for  radar  cross-section,  infrared  signature,  visual,  acoustics, 
and  emissions  was  a  new  discipline  and  a  new  challenge,  not  only  in  developing  fonnat  that 
could  be  tested  and  verified,  but  also  in  the  required  levels  for  each  of  the  signature  areas.  The 
program  specification  tree  developed  as  part  of  the  contract  required  the  Low  Observables 
Specification  to  be  developed  as  an  addendum  to  the  Weapon  System  Specification.  During  the 
B-2  source  selection,  the  specification  addendum  was  developed  jointly  by  the  Air  Force  and 
contractor  using  the  data  from  the  RATSCAT  tests  and  with  the  evaluators  estimating  the 
operational  effect  of  the  patterns  on  penetration8.  The  operational  effectiveness/mission  analysis 


8  USAF/RDQ  contracted  with  the  Calspan,  Buffalo,  NY  to  conduct  preliminary  operational 
effectiveness/mission  analysis  that  was  running  in  parallel  with  the  evaluation. 
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specialists  from  both  the  government  and  contractor  assessed  the  required  level  of  signature 
against  a  multitude  of  threat  lay  downs.  Soviet  threat  radar  capabilities  were  well  known  against 
various  levels  of  cross-section  vehicles  and  against  some  of  the  US  countermeasures.  As  the  two 
teams  conducted  their  analyses  and  compared  results,  the  required  levels  for  the  radar  signatures 
were  developed  through  an  iterative  process.  However,  it  was  only  developed  using  preliminary 
patterns  and  estimates  of  penetrability  and  not  a  war  game  scenario  against  multiple,  netted 
radars  and  specifically  located  targets  as  would  typically  be  done  in  a  full  Analysis  of 
Alternatives  (AO A).  The  contractors  did  not  have  the  means  (tools,  people,  approved  war-game 
computer  programs)  to  conduct  comprehensive  penetration  analysis.  The  government  had  the 
capability  (but  not  full  spectrum  of  capability  for  the  conduct  of  the  source  selection)  and  shared 
their  result  with  the  contractors.  The  two  teams  then  constructed  the  fonnat  and  wording  of  the 
specification  jointly,  greatly  enhancing  the  understanding  of  the  requirements  by  all  parties.  The 
resultant  RCS  specification  table  was  based  on  the  estimated  performance  of  the  patterns  against 
the  radars  and  was  written  in  terms  of  50%  and  90%  “exceedances”  for  the  azimuths  and 
elevations  of  interest. 

All  the  specifications  developed  during  source  selection  were  part  of  the  contract  between 
Northrop  and  the  government  except  the  RCS  specification  addendum.  Both  the  contractor  and 
government  agreed  the  data  on  the  configuration  was  not  sufficiently  mature  and  that  the  RCS 
model  required  updates  and  further  testing.  Further,  they  agreed  on  the  need  to  conduct 
additional  penetrability  analysis  with  refined  data  before  the  table  could  be  completed  with  the 
confidence  necessary  for  a  design  basis.  To  assure  this  had  time  to  mature;  a  B-2  specific  force- 
on-force  campaign  model  was  developed  and  was  functional  by  PDR  2.  This  model  would  test 
the  B-2  force  capability  annually  as  the  design  matured  and  the  nature  of  the  threat  improved. 

The  independent  variables  were  the  bomber’s  projected  aero  and  RCS  performance.  Target 
locations  and  the  Soviet  Union’s  estimated  air  defense  order-of-battle  were  provided  by  the 
USAF.  A  number  of  unaided  B-2  sorties,  on  the  order  of  25,  were  mission-planned  using  what 
ultimately  became  the  operational  B-2  mission  planning  computer  model.  The  missions  were 
“flown”  against  the  un-degraded  threat  and  the  statistical  outcomes  combined  into  a  “probability 
of  mission  success”  for  the  forced  structure.  The  force  “probability  of  survival”  was  also 
addressed.  This  annual  analysis  effort  helped  give  decision  makers  insight  into  the  cost-benefit 
of  the  B-2  force  as  it  was  being  developed  [3,  Cashen],  A  contractual  agreement  was 
established  to  finalize  the  Observables  Specification  as  a  function  of  “mutual  agreement”  after 
both  large  scale  high-quality  model  tests  and  after  additional  survivability/mission  penetrability 
analysis  could  be  conducted.  The  process  to  derive  a  final  set  of  requirements  was  time 
consuming  and  put  both  the  contractor  and  government  at  risk  from  contract  award  to  signing. 
The  benefit,  though,  was  the  derivation  of  a  clearly  understood  set  of  requirements  that  all  parties 
reached  with  mutual  agreement.  The  specification  addendum  was  placed  under  configuration 
control  shortly  after  PDR  2  [3,  Sunkes]. 

3,1.7  Low  Altitude  Modification  Request  (MR) 

The  evaluation  of  the  contractors’  proposals  proceeded  on  site  at  the  contractors’ 
facilities  throughout  December  1980,  through  January  and  into  February  1981.  The  Source 
Selection  Advisory  Council  (SSAC)  received  regular  briefings  on  the  progress  of  the  evaluation 
and  the  outcome  of  the  ongoing  survivability  assessment.  The  SSAC  concluded  that  growth 
provisions  for  low  altitude  capability  would  be  a  prudent  hedge  against  an  ever-changing  and 
maturing  radar  threat  operational  throughout  the  Soviet  Union.  Accordingly,  a  Modification 
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Request  to  the  RFP  was  issued  in  April  1981  to  request  a  study  for  the  impact  on  the  design  to 
include  a  significant  low  altitude  penetration  capability,  beyond  the  fallout  capability  from  the 
high  altitude  designs.  The  scope  of  the  request  was  to  examine  completely  new  designs,  in 
addition  to  studying  a  modification  to  proposal  baseline  of  a  high  altitude  cruise  design  approach 
currently  favored  by  each  contractor  and  the  primary  Air  Force  user,  the  Strategic  Air  Command 
(SAC).  The  redesign  activity  involved  the  contractors’  design  teams  and  the  Air  Force  technical 
specialists  (mostly  from  the  list  of  the  original  evaluators  who  were  called  back  to  work  on  the 
program  for  several  more  weeks).  The  combined  contractor/Air  Force  team  jointly  examined  the 
trade-off  between  survivability,  low  altitude  penetration  speed  and  altitude,  and  the  impact  on  the 
range  and  cruise  performance  of  the  primary  high-altitude  design  point.  The  resultant  design  that 
emerged  from  this  integrated  systems  engineering  activity  was  a  modification  to  the  baseline 
high-altitude  design  approach.  The  structure  was  beefed  up  by  about  10,000  pounds  but  the 
basic  structural  design  approach  was  retained.  Most  of  the  subsystems  were  immature  at  this 
time  and  were  not  substantially  impacted. 

One  of  the  changes  added  an  isolation  pallet  to  the  Northrop  configuration  in  the  cockpit 
to  mount  the  ejection  seats  and  instrument  panel.  The  purpose  of  the  pallet  was  to  improve  ride 
quality  to  increase  the  crew’s  perfonnance  during  long  exposures  to  turbulence.  Later  system 
engineering  studies  on  the  effect  of  the  pallet  showed  it  was  too  low  in  frequency  and  amplitude 
to  damp  the  damaging  effect  of  turbulence  on  the  crew’s  performance,  so  it  was  deleted.  This 
interaction  of  the  two  teams  during  this  redesign  activity  further  solidified  what  would  emerge  as 
a  highly  integrated  contractor/Air  Force  team  that  worked  closely  throughout  the  entire  design, 
development,  and  production  phases  of  the  program. 

A  clean  sheet  analysis  examined  many  alternatives  to  optimize  low  altitude  penetration 
capability  (which  had  originally  been  examined  in  the  ASPA  studies),  but  in  every  case, 
emphasizing  the  low  altitude  mission  drastically  reduced  high-altitude  mission  range.  Most  of 
the  configurations  required  afterburners  to  meet  takeoff  requirements  and  extensive  refueling  to 
meet  the  defined  penetration  missions.  All  new  designs  were  discarded  as  poor  candidates  for  an 
optimized  strategic  bomber.  The  study  confirmed  it  was  most  cost  effective  and  operationally 
effective  to  modify  the  high  altitude  design  to  perform  the  low  altitude  mission  than  to  design  for 
only  low  altitude  and  try  to  extend  the  range  by  making  a  larger  aircraft. 

3,1.8  Contract  schedule 

The  contract  schedule  was  developed  by  the  Source  Selection  Evaluation  Board,  SSEB, 
(under  the  guidance  of  the  Source  Selection  Advisory  Council,  SSAC)  throughout  the  evaluation 
process  in  1981.  The  contractors  had  proposed  schedules  based  on  reaching  first  flight  in  48 
months  from  go-ahead.  This  was  responsive  to  the  RFP  but  left  many  questions  regarding  risk 
reduction  and  risk  mitigation  prior  to  the  commitment  of  the  large  amount  of  resources  necessary 
for  a  Full  Scale  Engineering  Development,  FSED  program.  The  SSEB  judged  the  schedule  as 
high  risk  and  suggested  to  the  SSAC  a  program  of  60  months  to  first  flight  with  a  one  year  initial 
FSED  program  to  allow  time  for  risk  reduction.  This  was  briefed  to  the  SSAC  who  requested  a 
schedule  that  allowed  108  months  to  first  flight.  The  SSEB  disagreed  with  the  long  schedule, 
claiming  it  was  also  high  risk  because  the  team  would  proceed  too  slowly  for  too  long;  it  would 
be  unlikely  that  the  team  could  accelerate  to  the  required  FSED  pace  once  risk  reduction  had 
been  achieved.  After  much  deliberation,  a  72  months  schedule  to  first  flight  was  approved.  This 
allowed  a  two-year  period  for  risk  reduction  and  risk  mitigation  through  the  risk  closure  planning 
process. 
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One  other  key  decision  was  to  approve  a  combined  Full  Scale  Engineering  Development 
(FSED)  program,  together  with  an  Initial  FSED  phase  for  formal  risk  reduction.  The  purpose  of 
the  Initial  phase  was  to  formally  structure  a  risk  reduction  program  prior  to  committing  the  large 
funding  required  to  start  the  FSED.  This  allowed  a  risk  reduction  activity  to  lower  the  risk  to 
“moderate  to  low”  prior  to  PDR  2.  The  benefit  of  including  it  in  a  complete  FSED  program  was 
to  avoid  separate  contracts  and  avoid  re-entering  the  Air  Force  decision  process  [3,  Glenn]. 
Finally,  a  cost  plus  incentive  fee  structure  was  developed  for  the  contract9.  The  funding  profile 
for  this  program  was  then  developed  and  became  the  baseline  for  the  contract. 

3.2  Contract  Award 

Northrop  was  announced  as  the  winner  of  the  competition  on  17  October  1981  and  the 
$9.4B  FSED  contract  was  signed  on  4  December,  1981.  The  schedule  for  all  major  program 
milestones  is  shown  in  Table  3-3,  which  shows  the  original  contract  schedule  and  the  actual  date 
upon  which  the  event  occurred. 


Table  3-3.  B-2  Major  Program  Milestones 


Milestone 

Contract  Date 

Contract,  MAC 

Actual  MAC 
Achieved 

Contract  Award 

December  1981 

PDR  1 10 

October  1982 

11 

11 

Configuration  Freeze 

July  1983 

19 

19 

PDR  2 

Mar-  Apr  1984 

28 

28 

ICDs 

June  1984 

30 

32 

CDR 

December  1985 

48 

48  structures 

51  Engine/inlet 

54-56  subsystems 

First  Flight 

December  1987 

72 

90 

Legend 

PDR  -  Preliminary  Design  Review  CDR  -  Critical  Design  Review 

ICD  -  Interface  Control  Documents  MAC-  months  after  contract  go-ahead 

A  significant  feature  of  the  risk  reduction  phase  was  the  incorporation  of  the  Air  Force 
Research  Laboratory’s  Manufacturing  Technology  Division  (MANTECH)  efforts  into  the  B-2 
program.  This  was  a  vital  strategy  to  reduce  manufacturing  and  fabrication  risk  of  the  large- 
scale  composite  parts  required  for  the  program  success.  Through  the  B-2  SPO,  contracts  were 
given  to  Vought  for  fastener  insertion  in  composites,  large  scale  articulating  head  tape  laying 
machines,  composite  water  jet  cutting  techniques,  and  non-destructive  verification  of  completed 
parts.  Boeing  received  MANTECH  contracts  for  pultrusion,  autoclave  methods,  ultrasonic 
inspection  and  machining.  Northrop  received  authorization  for  development  of  a  Material 
Handling  System  and  loading  of  radar  absorbing  material  (RAM). 


9  Fixed  price  contract  strategies  were  discussed  during  the  source  selection  process,  but  were  never  a 
serious  consideration  [3,  Glenn]. 

10  PDR  1  was  a  milestone  to  approve  several  of  the  subsystem  specifications,  the  defensive  suite 
specification,  and  the  weapons  complement.  PDR  2  was  a  classic  PDR. 
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3.2.1  Systems  Engineering  Organizations 

The  Air  Force  System  Program  Office  (SPO)  was  very  interested  in  a  formal  systems 
engineering  organization  and  formal  systems  engineering  processes  that  would  be  defined, 
documented,  and  followed  by  the  prime  contractor  and  the  two  major  subcontractors.  A  formal 
Systems  Engineering  Management  Plan  (SEMP)  was  not  a  contract  requirement  in  the  original 
contract,  but  the  work  plans  stipulated  a  formal  flowdown  of  the  top  level  weapons  systems 
requirements  into  system  functional  specifications  as  part  of  the  approved  specification  tree11. 
The  contract  required  development  of  six  configuration  item  specifications  at  a  level  below  the 
Air  Vehicle  specification: 

•  Flight  control 

•  Avionics 

•  Radar 

•  Armament 

•  Low  observables 

•  Software 

Systems  engineering  on  the  B-2  program  was  federated  with  many  organizations 
participating  in  the  execution  of  the  systems  engineering  process.  Described  herein  are  the 
primary  organizations  that  existed  during  the  majority  of  the  time  frame  from  program  go  ahead 
to  one  year  after  CDR.  These  organizations  were  instrumental  in  implementing  the  systems 
engineering  process  throughout  the  program,  for  allocation  of  requirements,  and  assuring  the 
design  WBS  Task  teams  were  integrated  in  their  efforts.  [3,  Griskey] 

Weapons  Systems  Engineering  (WSE) 

The  Weapon  Systems  Engineering  (WSE)  organization  was  established  purposefully  to 
focus  on  the  evaluation  of  the  weapon  system’s  mission  effectiveness,  survivability,  and 
vulnerability,  and  at  the  same  time  be  the  repository  for  all  stealth  technology  development  and 
evaluations.  This  unique  “marriage”  of  the  classical  weapon  systems  analysis  system 
engineering  functions  and  the  stealth  technology  design  development  activities  was  driven  by 
two  factors:  (1)  the  fact  that  the  technology  development  activities  were  heavily  directed  by  the 
constant  interchange  with  the  survivability  analysis  function  to  assess  the  “value”  of  the  RCS 
signature  achieved  in  the  context  of  the  threat  systems;  and  (2)  the  fact  that  by  combining  both 
these  activity  groups  into  one  organization,  the  Program  had  consolidated  the  two  generators  and 
repositories  of  Level  IV,  Top  Secret  data  which  required  special  handling  and  protection  even  in 
program  areas.  (The  Air  Force  also  organized  their  functions  similarly  and  they  reported  to  the 
Director  of  Engineering  through  the  Chief  Systems  engineer.) 

The  WSE  organization  consisted  of  eight  separate  groups:  system  analysis;  survivability 
analysis;  vulnerability  analysis  (including  nuclear  hardening);  Low  Observables  (LO)  technology 
engineering;  LO  materials  &  processes  development;  LO  materials  laboratory;  anechoic 
laboratory;  and  Grey  Butte  test  range.  The  last  two  groups  were  removed  from  the  B-2  Program 
chain  and  became  a  Division  facility  for  use  by  the  entire  Division  three  years  later.  The 


11  The  SEMP  in  Appendix  5  is  reflective  of  the  organization  in  1989. 
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activities  of  the  six  principal  organizations  are  discussed  in  the  following  paragraphs.  The  latter 
two  organizations  roles  are  inferred  by  their  titles:  the  anechoic  laboratory  was  a  specific  facility 
that  could  accomplish  RCS  measurements  of  specific  full-scale,  embedded  aircraft  antenna 
models  and  aircraft  full-scale,  edge  assemblies;  and  the  latter,  was  a  company-owned,  test  range 
where  small-scale  complete  aircraft  models  and  large-scale  models  of  specific  design  features 
(e.g.  inlets)  could  be  tested  on  a  pole  at  various  bandwidths,  polarities,  and  attitudes. 

The  classical  weapon  system  analysis  functions  -  mission  effectiveness,  survivability  and 
vulnerability  -  were  established  as  separate  organizations  because  of  the  amount  of  activity  that 
each  had  to  perfonn.  The  mission  effectiveness  group  was  the  repository  for  all  threat  data 
furnished  by  the  USAF’s  Foreign  Technology  Division  (FTD)  and  the  “what  if’  Red  Team  of 
scientists  that  the  USAF/RDQ  employed  at  MIT  to  “challenge”  the  development  team.  The 
mission  effectiveness  organization  developed  a  “force-on-force”  campaign  model  that  was  used 
to  evaluate  the  effectiveness  of  the  B-2  force  capability  annually  as  the  design  matured  and  the 
nature  of  the  threat  improved.  Target  locations  and  the  Soviet  Union’s  estimated  air  defense 
order-of-battle  were  provided  in  threat  documents.  A  number  of  unaided  B-2  sorties  (approx.  25) 
were  mission-  planned  using  what  ultimately  became  the  operational  B-2  mission  planning 
computer  model.  The  missions  were  “flown”  against  un-degraded  threat  defensive  systems  and 
the  statistical  outcomes  combined  into  a  “probability  of  mission  success”  for  the  force  structure. 
Force  “probability  of  survival”  was  also  addressed  as  a  function  of  stealth  capability.  This  annual 
analysis  effort  helped  give  decision-makers  insight  into  cost-benefit  of  the  B-2  force  as  it  was 
being  developed  [3,  Cashen]. 

The  survivability  analysis  group  provided  support  for  the  mission  effectiveness  group  by 
providing  “probability  of  survival”  data  for  the  aircraft  against  each  of  the  defensive  systems 
individually,  as  well  as  survivability  against  integrated  defensive  systems.  In  addition,  the  group 
provided  data  to  guide  the  LO  technology  development  staff  to  help  focus  their  development 
efforts  by  identifying  where  improvements  were  required  against  specific  threat  systems.  The 
group  was  the  repository  of  all  signature  data  for  the  B-2  for  each  signature  type:  radar  cross 
section  (RCS);  infra-red  (IR);  visual;  electromagnetic  emissions;  and  acoustic.  The  data 
included:  frequency,  polarity,  and  elevation  for  RCS;  wavelength  and  emissivity  for  IR; 
brightness,  background,  etc.  for  visual;  Low  Probability  of  Intercept  RF  characterization;  and 
decibel,  range  from  source,  etc.  for  acoustic.  The  LO  technology  group  and  a  series  of  small, 
specialty  sub-contractors  employed  by  them  helped  develop  the  data  base  as  part  of  the  Program 
effort. 

The  vulnerability  group  had  the  responsibility  to  analyze  the  aircraft  design  and  identify 
vulnerable  areas  against  conventional  weapons,  electromagnetic  pulse,  etc.  This  group  also  had 
the  responsibility  to  assure  the  design  provided  “hardening”  of  the  aircraft  against  nuclear 
radiation  as  a  function  of  encountering  such  an  environment  as  part  of  conducting  a  SIOP 
mission.  To  assure  this  requirement  was  satisfied;  a  specialist  contractor  in  nuclear  hardening 
was  used  to  augment  the  Program  team.  The  expanded  group  reviewed  all  the  detailed  design, 
identified  areas  for  re-design  or  modification  for  all  vulnerabilities,  and  reported  directly  to  the 
Chief  Engineer  and  the  Program  Manager  any  areas  of  deficiency.  They  also  established  the  test 
requirement  for  the  special  test  facility  of  the  USAF  for  testing  nuclear  hardness. 

The  LO  Technology  group  was  the  group  that  had  total  responsibility  for  defining  the 
aircraft’s  external  shape  that  would  satisfy  the  LO  requirements  and  achieve  the  signature  levels 
ascribed  in  the  contract  specification  addendum.  They  had  responsibility  for  advising  the  design 


28 


organizations  on  design  details  that  would  affect  the  aircraft’s  signature;  conducting  tests  of  all 
external  features  that  could  affect  the  signature  to  verify  the  design  approach;  maintaining  a 
signature  budget  and  status  report  for  each  major  assembly  of  the  aircraft;  and  reporting 
periodically  to  the  senior  engineering  and  program  management  of  both  parties.  They  also  had 
responsibility,  in  conjunction  with  the  LO  Materials  &  Processes  development  laboratory,  to 
develop  and  test  all  materials  and  processes  used  for  achieving  the  signature,  in  addition  to 
aircraft  shaping.  For  the  latter,  they  had  the  responsibility,  in  conjunction  with  the  Aerodynamics 
group,  to  ascribe  the  requirements  for  shaping  the  aircraft  and  “buy-off’  of  the  external  mold 
lines  and  internal  lines  of  the  engine  inlet  and  exhaust  ducts  defined  by  the  Loft  group. 

The  LO  Materials  &  Processes  group  had  the  responsibility  for  developing  and  verify  all 
LO  materials  and  processes  used  in  the  build  of  the  aircraft.  They  conducted  material  reviews 
with  industry,  developed  new  materials  required  to  achieve  solutions  to  detailed  aircraft  design 
issues,  and  tested  the  materials  and  application  processes  in  both  the  classical  “M&P”  sense  and 
for  their  signature  effectiveness.  This  group  was  an  unsung  “hero”  of  the  Program  and  accounted 
for  many  technology  breakthroughs. 

Avionics  Systems  Engineering  (ASE) 

The  avionics  systems  engineering  group  continued  from  their  system  baseline  developed 
during  the  proposal  phase  and  matured  the  flowdown  of  requirements  from  the  avionics 
equipment  and  into  the  other  subsystems  that  provided  power,  cooling,  and  other  services.  The 
avionics  systems  engineering  group  was  responsible  for  all  aspects  of  the  critical  item 
specifications  within  the  avionics  group  and  responsible  to  coordinate  and  approve  other 
subsystems  specifications  and  vendor  design  approaches.  They  were  responsible  to  allocate 
requirements  and  monitor  the  progress  of  other  subsystems  in  meeting  the  avionics  requirements. 
Avionics  also  ran  their  own  avionics  technical  review  control  board  (ATRB)  within  their  group 
to  make  reallocations  within  their  own  subsystems  without  going  to  the  program  configuration 
control  board.  The  head  of  avionics  systems  engineering  chaired  the  avionics  ATRB  up  to  PDR 
2,  after  which  all  changes  were  remanded  to  the  program  CCB  [3,  Conklin],  For  the  B-2,  the 
avionics  architecture  drove  the  weapons  system  architecture  and  much  of  the  subsystems  design 
service  requirements. 

The  avionics  systems  engineering  organization  also  defined  requirements  for  the  flying 
test  bed  (FTB),  a  KC  135  bailed  by  the  Air  Force  to  Northrop  to  install  the  brass  board  and 
breadboard  avionics  systems  in  their  early  development  stage.  This  outstanding  integration  tool 
assisted  in  early  identification  of  problems,  led  to  early  resolution  of  incompatibilities,  and 
greatly  facilitated  the  maturity  of  the  avionics  suite.  The  FTB  tested  much  of  the  equipment 
before  it  was  flown  on  the  B-2.  Systems  engineering  also  derived  requirements  and  built  the 
Systems  Integration  Laboratory  (SIL)  at  Pico  Rivera  and  managed  the  testing  conducted  at  this 
facility.  The  SIL  eventually  included  all  the  hardware  and  software  operating  together  prior  to 
first  flight  as  a  further  risk  reduction  to  late  discovery  of  system  problems. 

One  founding  principle  for  the  design  and  development  process  was  the  extensive  use  of 
ground  testing  in  a  pyramid  from  component  to  subsystem  to  subassembly  to  integration. 
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Air  Vehicle  System  Engineering  (A/V  SE) 

Air  Vehicle  System  Engineering  was  organized  to  encompass  air  vehicle  configuration 
management  in  the  broadest  sense.  The  responsibility  for  classic  configuration  data 
management  was  located  in  the  Program  Operations  and  Control  organization  reporting  to  the 
program  office.  The  group  consisted  of  the  following  sub-groups:  Configuration  Design  &  Loft; 
Flight  Sciences;  Flight  Controls;  Structures  Technology  (inch  External  Loads;  Structure 
Analysis;  Structure  Dynamics);  Mass  Properties;  Safety  Engineering;  Human  Factors. 

Logistics  Systems  Engineering 

The  Logistics  Organization  at  Northrop  was  assigned  the  classic  responsibilities 
associated  with  the  supportability  requirements  for  a  future  weapon  system.  A  new  feature  was 
added  to  this  organization  that  was  unique  to  the  Aerospace  industry  and  clever  in  its  execution. 
This  new  feature  of  the  Logistics  Systems  Engineering  group  was  Reliability  and  Maintainability 
(R&M)  engineering  cognizance.  The  purpose  of  this  construct  was  to  emphasize  the  importance 
of  R&M  and  elevate  its  authority.  This  construct  operated  exceptionally  well  by  integrating  their 
personnel  across  the  design  teams.  The  Air  Force  SPO  retained  R&M  responsibility  within 
engineering.  The  net  effect  was  that  R&M  had  two  voices  through  the  management  chain  to 
surface  their  issues,  effectively  raising  the  importance  and  reporting  levels  of  the  “ilities”.  The 
process  achieved  a  substantial  milestone  in  weapon  system  reliability  for  hardware  and  software, 
which  even  today  is  remarkable  for  a  complex  weapon  system. 

In  examining  the  current  maintenance  data  for  the  B-2,  the  bulk  of  the  maintenance  effort 
is  performed  on  the  surface  treatment  to  maintain  low  observability.  The  systems  engineering 
process  noted  this  was  a  problem  for  second  or  third  generation  stealth  aircraft  and  included 
surface  preparation  in  the  original  initial  FSED  risk  reduction/mitigation  plan.  The  state-of-the- 
art  in  1981-1985  when  the  LO  surfaces  and  treatments  were  baselined  was  not  as  mature  as 
current  processes  and  materials.  Today,  aircraft  are  performing  much  better  in  this  area  of  LO 
maintainability,  but  the  B-2’s  performance  (higher  manhours  per  flight  hours  for  LO 
maintainability)  is  more  a  fact  of  the  technology  of  the  mid-1980s  than  a  failure  on  the  systems 
engineering  process. 

The  Logistics  Systems  Engineering  group,  working  in  concert  with  their  engineering 
counterparts  within  Northrop,  Boeing,  Vought,  and  from  the  SPO,  established  the  allocation  for 
supportability  requirements  to  each  subsystem,  system  element,  and  the  structure  assembly. 

They  established  design  criteria  based  on  lessons  learned  from  similar  equipments;  assured 
inclusion  of  supportability  requirements  into  all  procurement  specifications;  established 
reliability  growth  test  criteria  for  all  system  complements;  closely  monitored  the  progress  of 
subcontractor  and  vendor  designs  and  testing.  This  group  also  developed  the  specifications  for 
all  automated  test  and  training  equipment,  and  simulators  and  directed  the  development  of  the 
new  support  process  for  maintaining  low  observables  in  the  field.  This  group  was  a  very 
effective  part  of  the  program  systems  engineering  process.  Much  of  the  success  for  the  achieved 
R&M  for  the  hardware  and  software  can  be  attributed  to  this  group. 

Lastly,  there  was  an  additional  feature  that  had  a  very  large  impact  on  the  design  and 
development  of  the  B-2  weapon  system  -  Primary  System  Reliability  (PSR).  The  establishment 
of  a  very  ambitious  level  of  PSR,  combined  within  the  logistics  systems  engineering  construct, 
were  the  two  primary  factors  contributing  to  the  demonstrated  system  reliability.  PSR  was  such 
an  overwhelming  and  difficult  requirement  to  achieve,  it  may  well  have  been  the  single  most 


30 


difficult  of  all  the  requirements,  overshadowing  even  radar  cross-section.  The  basic  PSR 
requirement  stipulated  in  the  System  Specification  was  a  90%  probability  that  the  last  weapon  of 
the  suite  of  missions  had  to  be  delivered  within  the  required  circular  error  probability  (CEP). 

This  was  an  enonnously  difficult  requirement  to  meet.  The  requirement  was  derived  from  the 
SAC  mission  criterion  that  computes  how  and  what  type  of  weapon  is  assigned  to  specific 
targets.  The  algorithm  computes  the  probability  of  damage  given  such  factors  as  the  probability 
of  a  successful  strike  and  the  reliability  of  the  weapon.  The  process  to  allocate  this  very  difficult 
requirement  necessitated  each  and  every  subsystem  to  design  for  very  high  reliability  and  an 
added  degree  of  redundancy.  During  operations  in  the  Balkans,  the  B-2  demonstrated  a  PSR  of 
0.89  [5], 

Vought  Systems  Engineering 

Vought  organized  their  engineering  staff  into  a  classic  project  organization  with  a  system 
engineering  office  and  lead  project  WBS  Task  Team  leaders  reporting  directly  to  the  chief 
engineer.  The  function  for  the  intermediate  wing  was  primarily  structures,  zone  management, 
composite  design  and  construction,  interface  management,  and  subsystems  routing  in 
installation.  Vought  had  two  major  development  responsibilities;  they  had  to  develop  &  prove 
the  process  for  fabrication  and  assembly  of  the  inlet  assembly  and  they  had  to  develop  and  test 
and  verify  the  concept  for  cooling  the  aft  deck  assembly.  The  requirements  were  derived 
requirements  from  their  specification  and  ICD’s  with  Northrop  and  Boeing.  Vought’s 
organization  was  not  fully  implemented  as  an  IPT  structure  because  they  stopped  short  of 
assigning  cross-functional  people  to  the  project  lead. 

Boeing  Company  Systems  Engineering 

Boeing  organized  its  program  structure  in  a  form  that  met  the  B-2  Program  needs  and 
incorporated  its  previous  experience  in  both  Military  and  Commercial  programs.  A  Systems 
Engineering  function  was  established  from  the  very  beginning.  A  senior  Program  SE  manager 
was  assigned.  His  role  included  several  functions:  Systems  Engineering  integration, 
coordination  with  Northrop  and  the  significant  contractors,  such  as  Vought,  technical 
specifications  and  interface  control  document  management,  and  overall  program  technical 
integration,  including  our  business  and  contracts  functions.  Boeing  had  specific  areas  of 
responsibility:  outboard  wing,  aft  center  wing,  landing  gear,  fuel  system,  offensive  avionics, 
weapon  launchers,  and  integration.  Each  area  had  its  own  sub-team  management.  There  was  a 
huge  effort  to  integrate  with  the  rest  of  the  B-2  program  using  the  WBS  Task  team  structure. 
Each  area  had  its  systems  engineering  team.  The  leaders  of  these  sub-teams  reported  both  to 
their  chief  engineers  and  to  the  Program  Systems  Engineering  Manager.  The  work  was  very 
complex.  The  nature  of  the  work  started  at  the  typical  product  definition,  requirements  flow 
down  and  Spec/ICD  level,  then  phased  into  very  detailed  activity,  and  finally  into  demonstrating 
compliance  with  all  technical,  fonn,  fit,  and  function  requirements.  The  reconfiguration  and 
ensuing  changes  to  the  internal  systems  affected  the  work.  Fully  stuffed  structure,  stealth 
implications,  internal  avionics  tie  integration,  software,  etc  created  a  demanding  environment  to 
assure  internal  and  external  integration  by  the  SE  group.  The  aircraft  would  have  not  been 
successful  without  the  System  Engineering  function  [3,  Spitzer]. 

Air  Force  SPO  Systems  Engineering 

The  original  B-2  engineering  team  during  the  source  selection  consisted  of  35  engineers. 
As  those  35  engineers  migrated  back  to  their  original  program  offices,  new  personnel  were 
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assigned  to  the  program  to  manage  the  development  activity.  As  new  engineers  were  assigned, 
the  original  lead  engineer  for  the  technical  discipline  would  accompany  his  (her)  replacement  to 
meet  their  contractor  counterpart.  This  facilitated  the  continuation  of  the  already  established 
working  relationship  forged  during  the  source  selection  process  and  assured  a  continuation  of 
this  philosophy. 

The  SPO  Engineering  Directorate  was  a  classical  organizational  structure  with  four 
divisions: 

•  Systems  Engineering 

.  Airframe 

•  Avionics 

•  Crew  Station 

The  Chief  Engineer,  (later  elevated  to  the  Director  of  Engineering)  always  had  a  deputy 
chief  engineer.  The  people  integrated  their  efforts  with  the  other  SPO  Directorates  at  the 
working  level  and  always  worked  closely  with  their  Projects  Directorate  counterparts. 

The  program  progressed  from  the  initial  full-scale  development  program  and  the  risk 
reduction  areas  to  a  full-fledged,  fast-paced  development  program  by  the  time  of  the 
reconfiguration  in  the  middle  of  1984.  The  SPO  engineering  cadre  grew  to  60  people  by  early 
1985  and  still  consisted  of  highly  experienced,  well-trained  engineers  with  exceptionally  strong 
backgrounds  and  experience.  The  process  to  staff  the  SPO  at  the  time  of  contract  award  was 
interesting  and  effective. 

An  engineer  would  receive  a  phone  call  from  the  secretary  of  Mr.  Fred  Rail,  the  technical 
director  for  Aeronautical  Systems  Center.  Bessie  would  tell  the  engineer  that  he  (she)  was 
needed  for  a  meeting  in  Mr.  Rail’s  office  at  2  p.m.  tomorrow.  The  engineer  would  show  up 
typically  15  minutes  ahead  of  time  and  wait  on  the  couch  until  2  p.m.  The  door  to  Mr.  Rail’s 
office  would  be  closed  and  no  one  would  go  in  or  out.  At  2  p.m.,  Bessie  would  tell  the  engineer 
it  was  okay  to  go  into  the  room.  No  one  would  be  there  but  the  B-2  chief  engineer,  who  himself 
no  longer  existed  on  any  organization  chart.  He  would  be  sitting  in  Mr.  Rail’s  chair  at  the 
conference  table.  After  the  engineer  looked  around  and  saw  no  one  else  was  in  the  room,  they 
would  be  asked  to  sit  down.  The  chief  engineer  would  explain  that  the  person  was  wanted  in  the 
“black  hole”  for  a  project.  They  would  ask  what  they  would  be  doing  and  receive  the  answer,  “I 
can’t  tell  you”.  They  would  ask  numerous  questions,  all  receiving  the  same  answer!  After 
several  minutes  of  this,  and  there  would  be  a  resigned  sigh  and  finally,  after  being  assured  it  was 
a  great  program  and  an  important  job,  every  single  one  said,  “okay”.  After  the  agreement,  they 
had  a  short  period  of  time  to  close  any  actions  ongoing  in  their  past  assignment  before  reporting 
to  the  black  hole  and  essentially  disappearing  from  the  organization  chart.  The  engineering 
functional  (ASC/EN  home  office)  still  kept  their  records  but  they  were  co-located  and  not  shown 
on  any  other  organizational  chart.  It  was  the  responsibility  of  the  chief  engineer  and  Mr.  Rail’s 
staff  to  assure  that  the  engineers  received  their  promotions  and  performance  increases  consistent 
with  their  perfonnance  in  the  B-2  SPO.  Since  these  engineers  were  among  some  of  the  best, 
they  regularly  competed  for  and  won  bonuses  and  promotions.  This  helped  assure  that  new 
engineers  would  be  willing  to  be  assigned  to  the  SPO  because  they  knew  they  could  still  compete 
with  their  unclassified  program  (“white  world”)  counterparts  on  an  equal  basis. 
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It  was  essential  to  continue  to  staff  the  B-2  SPO  with  experienced  engineers  who 
understood  their  technical  discipline  and  the  role  of  requirements  in  development  programs. 
These  people  were  committed  to  cooperate  with  each  other,  with  the  contractors,  and  with  the 
user  to  develop  a  balanced  design  and  to  make  and  implement  the  decisions  required  to  make  this 
weapons  system  development  successful.  During  design  reviews  at  the  working  level,  the 
engineers  from  the  SPO  would  regularly  attend  the  meetings  and  assist  in  the  process.  The  using 
command  was  also  invited  to  design  review  meetings  and  technical  interchange  meetings  and 
they  attended  on  a  regular  basis.  SAC  had  a  staff  of  about  20  officers  stationed  at  SAC 
headquarters  in  Omaha  Nebraska  who  were  assigned  to  the  program  with  responsibility  of  a 
continuous  presence  in  the  program.  These  officers  played  a  vital  role  in  helping  the  engineers 
understand  the  conduct  of  the  SAC  mission  and  the  needs  of  the  crew  and  maintenance  people. 
The  SPO  engineers  helped  the  using  command  personnel  understand  the  implications  of 
requirements  that  exceed  that  which  would  be  required  to  satisfactorily  conduct  operations.  The 
constant  interaction  of  the  three  groups,  SAC  stating  their  needs,  the  SPO  defining  requirements, 
and  the  contractor  teams  designing  and  developing  the  hardware  and  software  was  a  key 
ingredient  in  the  operation  of  the  process. 

Chief  Engineers  Meetings 

The  company  chief  engineers  and  the  Air  Force  SPO  chief  engineer  met  every  four  to  six 
weeks  for  a  one-day  meeting.  The  purpose  of  these  meetings  was  to  rapidly  resolve  integration 
and  design  issues.  The  meeting  host  was  rotated  between  the  chief  engineer  for  Northrop, 
Boeing,  Vought,  and  the  Air  Force.  Responsible  engineers  and  their  team  for  a  particular  area 
under  study  would  brief  the  problem  and  alternatives.  The  team  would  consist  of  membership 
from  all  the  companies  and  the  SPO.  The  decision  was  made  as  to  how  best  to  proceed  and  the 
chief  engineers  agreed  to  implement  the  decision  immediately.  It  was  responsibility  of  each 
chief  engineer  to  assure  the  decision  was  communicated  to  the  program  manager  and  throughout 
his  or  her  own  organization;  it  was  also  their  responsibility  to  insure  contractual  integrity  of  the 
decision. 

These  meetings  were  a  highly  effective  systems  engineering  process  tool.  Prior  to  the 
meetings,  significant  integration  effort  and  assessment  of  alternatives  was  required  by  the  staff  to 
present  a  sound  solution  to  the  program  engineering  leadership.  None  of  the  engineers  wanted  to 
present  an  incomplete  resolution  in  this  forum.  This  was  essentially  a  technical  configuration 
control  board  although  each  of  the  design  teams  had  dedicated  contracts,  financial  management, 
manufacturing,  and  logistics  membership  as  part  of  their  team.  This  facilitated  communications 
and  contract  efforts  to  implement  the  decisions. 

There  were  other  major  subcontractors  that  also  became  involved  in  the  chief  engineers 
meetings  particularly  Hughes  and  General  Electric.  The  Hughes  contract  was  a  subcontract  to 
Northrop  and  the  General  Electric  contract  was  managed  by  the  SPO  for  the  basic  engine. 
Northrop  also  had  a  separate  contract  with  GE  for  the  design  and  development  of  the  exhaust 
nozzle/tailpipe.  The  working  relationships  with  these  two  contractors,  and  in  fact,  all  of  the 
subcontractors  and  vendors  were  excellent  and  consistent  with  the  working  relationships  among 
the  four  main  entities. 

3.2.2  Facilitization 

The  B-2  program  scope  was  so  large  that  conducting  the  program  within  a  single 
aerospace  corporation  was  considered  impractical.  The  program  started  at  the  same  time  the 
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Aerospace  industry  was  in  a  general  boom.  In  the  Los  Angeles  basin,  several  aerospace 
corporations  were  vying  for  the  engineering  talent.  During  the  source  selection  Lockheed  had 
announced  they  would  team  with  Rockwell  even  though  Rockwell  was  preparing  a  proposal  to 
develop  and  build  100  B- IB’s  in  response  to  Reagan’s  campaign  promise  to  restart  the  program. 
Northrop ’s  corporate  team  included  Boeing  and  Vought  and  was  considered  a  viable  competitor 
even  though  Northrop  had  not  been  a  prime  contractor  on  a  large  bomber  program  since  B-35/B- 
49  flying  wings  in  the  1940s.  They  had  been  the  prime  contractor  for  the  T-  38/F-5  programs 
and  considered  themselves  a  “fighter  house”.  It  had  taken  several  persuasive  conversations 
between  the  Air  Force  senior  leadership,  Lt.  Gen.  Stafford,  and  the  CEO  of  Northrop,  Tom 
Jones,  before  Northrop  agreed  to  participate  in  the  1980  study  contract  that  founded  the  B-2. 

The  full-scale  development  program  required  a  significant  infrastructure  expansion  from 
the  very  beginning  for  facilities,  capital  equipment,  laboratories,  staff,  and  security.  All  three  of 
the  major  corporations  undertook  a  substantial  capital  investment  program  that  exceeded  $2.5 
billion  .  A  brief  description  is  provided  in  order  to  capture  the  magnitude  of  these 
investments13. 

Northrop  Facility  Capitalization 

Two  separate  office  buildings  were  constructed  to  house  material  procurement, 
subcontract  management  organizations,  facilities  engineering,  and  the  operations  organization. 
Expansion  of  the  outdoor  radar  cross-section  range  modernized  the  capability  to  increase  data 
production  rates.  A  large  (2.5  million  square  foot  ex-Ford  plant)  was  acquired,  gutted,  and 
equipped  to  house  a  new  Northrop  Division.  The  new  secure  facility  at  Pico  Rivera,  California 
was  required  for  design,  development,  research,  laboratory  testing,  and  sub  assembly  of  the 
Forward  Center  Wing  and  all  the  edge  structures.  Program  Management  and  all  the  major 
functional  managers  from  the  program  also  had  their  offices  in  this  central  location.  This  facility 
provided: 

•  Workstations  and  offices  for  2,500  engineers,  scientists,  and  support  staff 

•  Dedicated  computer  complex  and  computer  design  rooms 

.  Flight  simulation  laboratory  with  accommodations  for  a  full-scale  iron  bird 

•  Avionics  laboratory  for  display  development 

•  Workstations  for  individual  avionics  software  development  and  hot  benches  for 
hardware/software  integration 

•  An  integrated  Avionics  and  Flight  Control  Laboratory 

•  Model  shops  (wind  tunnel  and  radar  cross-section  models) 

.  Anechoic  chambers 


12  All  indemnified  by  the  DOD/USAF. 

13  One  of  the  pre-contract  events  that  had  a  significant  impact  on  the  cost  of  the  program  was  the  effect  of 
security.  Security  was  listed  as  the  first  priority  in  the  government  Program  Management  Directive,  PMD.  The 
remaining  order  of  priority  was  technical,  schedule,  and  then  cost.  During  the  1980-1981  timeframe,  a  new  program 
security  guide  was  implemented  by  the  DOD  for  special  access  programs,  which  increased  the  cost  of  maintaining 
security  by  requiring  new  procedures.  This  was  to  have  a  profound  cost  impact,  later  assessed  at  15  to  20  percent  of 
the  total  program  cost,  little  of  which  was  included  in  the  original  cost  estimate. 
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•  Composite  fabrication  and  sub  assembly  facility,  including  clean  rooms 

.  Manufacturing  facility  with  automated  material,  tool  handling,  and  inventory 
storage  system 

•  Five  autoclaves 

•  A  major  structural  assembly  area  for  the  Forward  Center  Wing  assembly. 

Northrop  accepted  responsibility  for  the  design,  construction,  and  acceptance  of  a  secure 
final  assembly  facility  at  Palmdale  as  part  of  their  Total  System  Performance  Responsibility 
(TSPR)  by  executing  a  separate  contract  obligation  with  the  Air  Force.  Northrop  was 
responsible  to  equip  the  building  at  Site  4  of  Plant  42  in  Palmdale  to  accomplish  the  integration 
and  final  assembly,  system  checkout,  engine  run-up,  and  taxi  testing.  The  company  was  also 
responsible  for  modification  of  a  building  to  provide  for  the  aircraft’s  surface  preparation  and 
coatings  applications. 

Boeing  Facility  Capitalization 

Modifications  were  made  to  major  portions  of  the  existing  Development  Center  at  the 
Seattle  Boeing  Field  location  to  accommodate  the  design,  development,  and  production  of  the 
Aft  Center  Wing  and  the  Outboard  Wings.  This  included: 

•  Workstations  and  space  for  1,200  -  1,300  engineers,  scientists,  and  support 
personnel 

•  Full-scale  mock  up  areas  for  their  sub  assemblies 

•  Structural  test  laboratory 

•  Armaments  laboratory  for  the  development  of  the  rotary  launcher 

•  Office  space  for  the  managers 

•  Development  and  installation  of  the  world’s  largest  autoclave  (125  ft  by  25  ft); 

•  A  composite  pultrusion  facility 

•  Large-scale  composite  skin  bond  assembly  capability 

•  Fuel  laboratory  was  updated  to  test  the  entire  fuel  system  on  a  fuel  table  capable 
of  rotating  to  simulate  in-flight  attitudes 

Vought  Facility  Capitalization 

Modifications  were  also  made  to  Vought  facilities.  These  consisted  of: 

•  An  office  building  to  accommodate  a  dedicated  computer  complex 

•  Offices  and  workstations  for  approximately  750  engineers  and  support  personnel 

•  Modification  of  the  metal  fabrication  facility  to  accommodate  automated  handling 
of  working  process  and  raw  material  distribution 

•  Modification  of  assembly  building  to  accommodate  design  development  and 
production  of  the  Intennediate  Wing;  design  development  and  installation  of  a 
composite  tape  laying  machine  to  construct  three-dimensional  surfaces 

•  Installation  of  a  drive-matic  machine  for  titanium  fasteners 


35 


•  Developed  and  installed  automated  waterjet  cutting  capability  for  large  composite 
panels 

Air  Force  Facilities 

In  addition  to  facility  space  in  Palmdale,  CA  for  the  final  assembly,  construction  of  a 
secure  facility  at  Edwards  Air  Force  Base  called  South  Base  was  funded.  This  facility  provided 
office  space,  computers,  flight  test  instrumentation,  flight  test  operations,  flight  test  range 
instrumentation  for  both  Air  Force  personnel  and  the  contractor’s  contingent  of  the  Combined 
Test  Force. 

3.3  Full  Scale  Engineering  Development  (FSED)  Execution 
3.3.1  Risk  Closure  Plans 

Risk  closure  plans  were  the  primary  tool  used  throughout  the  program  to  identify, 
document,  and  mitigate  risks.  Individual  Risk  closure  plans  were  integrated  into  the  program, 
organization,  and  WBS  Task  Team  work  plans.  The  specific  risk  activities  that  were  assigned  to 
task  teams  included: 

•  RCS  testing  and  materials  development 

•  Aero/propulsion  integration  with  the  low  observables  requirements 

•  Large  scale  composite  and  Radar  Absorbing  Structure  development 

•  Radar  antenna  design  and  construction  of  a  working  model 

•  Inlet/engine/exhaust  integration  and  validation  of  aft  deck  air  flow  and  temperatures 

•  Aero  elastic  structural  response 

•  Avionics  suite  definition 

•  Subsystem  design  approach  and  perfonnance  testing 

•  Reliability  assessment  and  development  growth  testing 

The  Initial  FSED  (IFSED)  risk  reduction  areas  that  were  to  be  reduced  by  concentrated 
effort  leading  up  to  preliminary  design  review  (PDR-2)  are  shown  in  Figure  3-6.  Risk  closures 
plans  were  constructed  for  each  of  the  nine  areas  and  the  responsible  WBS  Task  team  was 
assigned  to  close  the  risks.  For  a  description  from  the  B-2  Systems  Engineering  Management 
Plan  (SEMP)  on  Risk,  see  Appendix  5. 

The  risk  closure  plan  concept  was  introduced  by  the  Northrop  program  manager,  first  on 
Tacit  Blue  in  the  Spring-Summer  of  1980,  and  then  to  the  ASPA  proposal  team  in  September, 
1980.  It  was  the  dominant  program  tool  for  the  two  and  one  half  years  during  the  IFSED 
program  for  risk  reduction  and  was  used  to  develop  the  work  plans  for  the  individual  risks  in 
Figure  3-5.  It  was  also  integrated  by  the  Program  Operations  and  Control  (PO&C)  organization 
into  the  Management  Information  Control  (MIC)  room  and  the  Responsible  Engineer  (or 
logistics  specialist,  manufacturing  lead,  Quality  Assurance  person,  etc.)  briefed  the  status  during 
internal  reviews  and  during  the  Quarterly  Program  Management  Review  (QPMR). 

The  risk  closure  process  was  used  throughout  the  entire  development  and  production 
program.  It  was  one  of  the  key  elements  that  contributed  to  the  program  success.  From  the 
beginning,  the  risk  closure  plans  were  constructed  by  the  WBS  Task  team,  owned  by  them,  and 
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closed  by  them.  At  no  time  did  any  other  organization  manage,  track,  chase,  or  in  any  other  way 
provide  a  non-value  added  oversight  function.  PO&C  only  provided  space  in  the  MIC  room. 


Figure  3-6.  Risk  Reduction  Plan  -  Areas  for  Interim  Full  Scale  Development  [6] 
Wing  Material  Decision 

A  significant  area  of  risk  for  the  B-2  air  vehicle  was  in  the  area  of  composite  materials. 
Northrop  and  two  major  subcontractors,  Boeing  and  Vought,  designed  the  original  proposal 
aircraft  with  a  significant  amount  of  composite  structure.  Northrop  proposed  all  of  the  edges  as 
composite  structure,  primarily  for  the  radar  cross-section  requirement  that  dictated  radar¬ 
absorbing  structure.  Boeing’s  proposal  for  the  aft  center  wing  and  the  outboard  wing  included 
significant  use  of  composites  as  major  aircraft  structure.  Vought’s  proposal  was  largely 
composite  and  titanium  primary  structure,  with  conventional  aluminum  where  it  was  more  cost 
effective  [3,  Patton].  The  Northrop  forward  center  wing  was  proposed  (and  still  is)  largely 
aluminum  construction. 

Composite  structure,  like  those  shown  in  Figure  3-7,  for  large  aircraft  sub  assemblies  was 
a  new  endeavor  in  the  1980-  1981  timeframe.  Composites  had  been  employed  for  secondary 
structure  for  several  major  weapons  systems,  but  the  engineering  data  base  and  operational 
experience  was  very  limited.  Production  applications  for  primary  structure  developed  by  the 
Laboratory  through  contracts  with  industry  were  Advanced  Technology  Demonstrators  (ATD), 
such  as  the  F-15  wing,  but  none  of  these  were  put  into  production.  The  B-2  team  faced  the  very 
difficult  task  of  employing  a  new  material  on  a  scale  that  no  program  or  company  had  employed. 
To  further  complicate  the  task,  the  proposed  design  approach  had  complex  load  paths  driven  by 
the  mission,  the  low  observables  requirements,  aerodynamics,  and  the  large  cutouts  on  the 
bottom  for  the  engine  bay  doors,  landing  gear  doors,  and  weapons  bay  doors.  All  of  these 
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requirements  necessitated  the  use  of  large,  complex  composite  structures  to  achieve  the  strength 
required,  using  the  flexibility  of  design  and  manufacturing  promised  by  the  emerging  composite 
technology.  If  only  conventional  metallic  structural  materials  like  aluminum,  steel,  and  titanium 
were  employed  in  the  design,  the  structures  experts  predicted  the  resultant  design  would  weigh 
so  much  that  there  would  be  no  practical  use  for  the  aircraft  [3,  Wilson].  Therefore,  the 
extensive  use  of  composites  required  in  the  design  was  considered  a  major  risk. 

The  B-2  program  constructed  a  risk  closure  plan  for  the  composites  as  part  of  the  FSED 
risk  reduction  phase  of  the  program  and  set  September  1983  as  the  wing  material  decision  date 
(WMDD).  The  team  of  the  best  talent  in  composites  from  Northrop,  Boeing,  Vought,  and  the 
Air  Force,  to  be  led  by  Boeing,  was  assembled  at  the  development  center  in  Seattle,  Washington. 
The  team  met  in  December  1981  and  developed  criteria  for  success  for  design  allowables, 
manufacturing,  tooling  (tool  life),  producability  (repeatability  and  cost  basis  data),  and 
supportability.  The  team  built  three  50  foot  long  wing  sections  representative  of  the  outboard 
wing  panels.  They  also  built  several  wing  box  sections  of  the  outboard  wing.  These  pieces  were 
extensively  tested  and  inspected.  Teardown  of  every  tested  piece  was  accomplished  and  results 
were  analyzed  against  the  pre-test  predictions  and  against  the  criteria. 

The  team  also  initiated  an  aluminum  wing  design  of  the  air  vehicle  made  of  conventional 
metals.  This  design  was  to  compare  the  weight,  cost,  schedule,  risk,  and  manufacturing 
approach  to  the  composite  design.  It  was  a  risk  mitigation  strategy  in  the  event  the  composite 
design  was  not  successful.  The  team  met  in  September  1983  to  review  the  work  and  results  of 
the  tests,  inspections,  and  analysis;  they  declared  the  risk  closed  and  the  composite  approach  as 
viable,  thus  establishing  it  as  the  B-2  program  baseline. 

The  primary  process  to  construct 
the  Risk  Closure  Plan  for  the 
composites  was  proposed  by  Northrop 
in  the  December  1980  response  to  the 
RFP  where  the  contractor  proposed  a  set 
of  manufacturing  and  fabrication  risk 
reduction  studies,  tasks,  and 
development  of  tools,  techniques,  and 
the  facilities  and  equipment  to  mature 
the  composites  technology.  The 
concept  put  forth  was  to  use  the  existing 
Air  Force  Materials  Laboratory 
contracts  to  fund  initiatives  to  mitigate 
manufacturing  and  fabrication  risk.  The 
Air  Force  program  office  formed  a  team 
of  specialists  to  refine  the  list  of  required  efforts  that  would  be  implemented  using  the  combined 
talents  of  the  government  and  industry,  and  augment  the  ongoing  efforts  of  the  Air  Force  Wright 
Aeronautical  Laboratory’s  Manufacturing  Technology  (ManTech)  Division.  This  was  a  vital 
strategy  to  reduce  design,  manufacturing,  and  fabrication  risk  of  the  large-scale  composite  parts 
required  for  the  program  success  and  was  managed  and  funded  by  the  B-2  SPO  through  the  B-2 
FSD  contract.  Using  program  money,  a  series  of  studies  and  funded  projects  were  conducted  by 
the  program  participants.  Tasking  was  given  to  Vought  for  fastener  insertion  in  composites, 
large  scale  articulating  head  tape  laying  machines  (working  with  Ingersol),  composite  water  jet 


Figure  3-7.  Large-scale  manufacturing  for  these 
layered  composite  materials  was  technologically 
immature  and  high-risk  during  the  early  program. 
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cutting  techniques,  non-destructive  test  and  verification  of  completed  parts.  Boeing  developed 
processes  and  equipment  for  pultrusion,  autoclave  methods,  autoclave  control  systems,  ultrasonic 
inspection,  and  tape  laying  equipment  with  Cincinnati  Milacron.  Hughes  received  Mantech 
money  to  build  new  antenna  mechanically  scanned  in  one  direction,  electronically  scanned  in  the 
orthogonal  direction.  Northrop  was  funded  for  their  large  scale  edge  design  and  manufacturing 
facility.  This  process  to  reduce  risk  and  mature  the  state  of  the  art  in  manufacturing  also  had  a 
positive  effect  on  the  overall  design  because  the  manufacturing  process  was  maturing  with  the 
engineering.  Manufacturing  and  the  logistics  functionals  (through  the  emphasis  on  reliability, 
maintainability,  and  supportability)  were  well  represented  in  the  early  design  process  in  the 
program.  The  ManTech  efforts  with  the  B-2  contractors  were  conducted  during  1981  to  1985. 

3.3.2  Preliminary  Design  Review  (PDR-1) 

PDR  1  incorporated  two  new,  major  engineering  activities,  both  of  which  had  significant 
changes  to  the  baseline  configuration.  The  first  of  these  changes  resulted  from  the  culmination 
of  the  avionics  suite  defensive  countenneasure  study.  Avionics  systems  engineering  and  the 
avionics  contingent  from  the  Air  Force  SPO  had  been  conducting  a  trade  studies  on  various 
defensive  suite  alternatives  as  an  enhancement  to  the  penetration  of  Soviet  defenses.  The  study 
examined  survivability  enhancement  through  the  use  of  countermeasures  specifically  applicable 
to  stealth  vehicles.  The  study  results  were  completed  at  PDR  1  and  formally  presented  to  the  Air 
Force  SPO  and  the  recommended  avionics  suite  was  approved.  The  approved  suite  became  part 
of  the  new  avionics  program  baseline  and  was  incorporated  in  the  avionics  specifications. 

The  second  change  was  the  incorporation  of  certain  provisions  for  a  third  crewmember. 
Mission  proficiency  and  crew  workload  studies  were  conducted  after  contract  award  and  showed 
that  with  the  combination  of  penetration  aids,  mission  planning  software,  display  algorithms, 
automation,  and  redundancy,  a  two-man  crew  was  fully  adequate  to  complete  the  specified 
missions.  However,  the  Air  Force  planners  reasoned  that  new  missions  and  unforeseen 
complexities  in  the  future  may  well  force  an  increase  in  workload  to  the  point  where  a  third 
crewmember  would  be  necessary.  Therefore,  after  an  extensive  trade  study  was  conducted  in  the 
months  leading  up  to  PDR  1 ,  the  SPO  decided  to  incorporate  space  and  structural  provisions  for 
the  third  crewmember.  This  necessitated  moving  the  avionics  that  was  currently  installed  in  the 
aft  part  of  the  crew  station  to  a  new  location  in  the  aft  of  the  aircraft,  behind  the  weapons  bays. 
The  upper  section  of  the  aft  crew  station  bulkhead  was  canted  backwards  at  the  angle  of  the  back 
of  the  ejection  seat  to  allow  for  the  installation  of  the  seat  rails.  This  further  resulted  in  moving 
weapons  bay  rotatory  launchers  back  slightly  to  allow  for  weapon  clearance  for  this  new  canted 
bulkhead. 

A  major  integration  tool  that  started  to  emerge  after  contract  award  and  eventually 
achieved  program  wide  acceptance  was  computer  aided  design  and  classified  networking. 
NCAD/NCAL  was  a  Northrop  Computer  Aided  Design  (NCAD)/  Northrop  Computer  Aided 
Lofting  (NCAL)  tool  developed  under  independent  R&D  that  was  extremely  effective  and  useful 
for  the  task  of  integrating  all  the  companies  and  their  design  staffs.  It  was  a  major  aide  to  the 
systems  engineering  process.  The  system  was  user  friendly,  very  capable,  and  easily  adaptable 
to  a  classified  network  among  the  companies.  While  CAD  tools  are  commonplace  now,  this 
technology  did  not  exist  in  the  early  1980s;  the  B-2  was  the  first  all-CAD  designed  aircraft  [3, 
Myers].  Its  ease  of  use  and  simplicity  facilitated  the  design  evolution,  spatial  allocations, 
requirement  tradeoffs,  was  a  great  aid  to  integration  across  the  interfaces,  and  a  boon  to  the  ease 
of  integration  of  the  assemblies  during  manufacturing. 
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3.3.3  Configuration  Freeze 

The  next  major  milestone  after  PDR-1  was  “Configuration  Freeze,”  scheduled  nine 
months  prior  to  PDR-2.  It  was  one  of  the  last  “Configuration-Driver”  risk  closure  activities  still 
open  from  the  Interim  FSED  risks.  It  was  four  and  one  half  months  prior  to  this  contractor- 
imposed  milestone  that  the  need  for  a  major  redesign  became  apparent.  The  redesign  would  be 
the  largest  single  internal  event  that  occurred  during  development  and  contributed  both  to  the  slip 
in  the  first  flight  date  and  to  the  cost  increase  of  the  program. 

The  Pre-contract  award  Modification  Request  for  high  subsonic,  low  altitude  penetration 
capability  imposed  a  derived  requirement  for  an  additional  low  altitude  gust  capability.  The 
team  recognized  that  the  higher  gust  loads  and  more  severe  spectrum  would  have  a  major 
influence  on  the  structural  design  loads.  The  team  developed  a  sophisticated  model  of  the 
complex  aero-servo-elastic  characteristics  of  the  air  vehicle,  including  steady  and  unsteady 
aerodynamics,  structural  dynamics  (derived  from  a  NASTRAN  finite  element  model),  as  well  as 
the  flight  control  laws  and  actuation  dynamics  in  order  to  quantify  the  achievable  level  of  gust 
load  alleviation.  This  integrated  structural  analysis  program  would  confirm  the  internal  loads 
concurrently  while  controlling  the  aircraft.  The  program  was  to  be  a  key  factor  in  assessing  the 
adequacy  of  the  structural  design  during  operations  at  low  altitude/high  speed  operations  in  the 
presence  of  significant  gust  loads.  In  particular  it  would  assess  the  adequacy  of  the  flight  control 
system  to  actively  reduce  the  airframe’s  dynamic  response.  Northrop  drew  on  the  expertise  and 
help  of  national  scientific  and  technology  leaders  from  USAF,  NASA,  members  of  all  three 
airframe  companies’  technical  staffs,  and  both  General  Electric  and  Minneapolis  Honeywell’s 
Advanced  Design  Center  to  facilitate  the  development  of  the  analytical  program14. 

The  analysis  was  scheduled  for  completion  in  December  1982  but  because  of  its 
complexity,  it  was  not  yielding  data  until  January  1983.  Meaningful  results  were  obtained  in 
early  February  1983  at  which  time  Air  Vehicle  Systems  Engineering  (A/V  S/E)  WBS  task  team 
leader  advised  the  Northrop  program  manager  that  the  results  revealed  a  substantial  wing 
bending  moment  increase  over  earlier  estimates  due  to  more  severe  aero-elastic  effects  incurred 
at  high  speed,  low  altitude  flight  conditions  and  the  inability  of  the  controls  to  provide  adequate 
load  alleviation,  while  still  controlling  flight  and  maneuvers.  Eighty  percent  of  the  wing  bending 
moment  came  from  the  first  bending  mode,  which  had  a  node  line  that  curved  behind  the 
outboard  controls  as  depicted  in  Figure  3-7. 

The  center  of  pressure  for  the  primary  pitch  control  surfaces  was  nearly  coincident  with 
the  first  wing  bending  node  line.  This  reduced  the  effectiveness  of  the  control  system  to  damp 
the  gust  induced  loads  associated  with  this  mode.  The  analysis  also  revealed  that  distribution  of 
the  carry  through  loads  across  the  centerline  was  strongly  asymmetric  with  the  forward  weapon 
bay  bulkhead  receiving  70  percent  of  the  total  root  bending  moment,  leaving  only  30  percent 
through  the  rear  bulkhead.  The  combination  of  increased  bending  moment  and  poor  load 
distribution  led  to  high  internal  loads  in  the  inboard  forward  wing  structure.  The  inefficient  fore 
and  aft  load  paths  were  brought  about  in  part,  because  of  the  large  cutout  in  the  bottom  of  the 
aircraft  for  the  weapons  bay  doors,  engine  bay  doors,  and  landing  gear  doors.  While  the  cutouts 
were  there  from  the  beginning  and  the  team  knew  they  would  affect  the  ability  to  control  the 


14  Of  particular  note  were  the  significant  contributions  made  by  Dick  Stone  of  Minneapolis  Honeywell  and 
Jerry  Newsom  and  John  Edwards  of  NASA  Langley 
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balance  of  loads  between  the  fore  and  aft  load  paths,  the  computer  model  confirmed  the 
unexpectedly  poor  70%  -  30%  split. 


Figure  3-7.  Structural  Bending  of  the  Wing  at  First  Bending 

A  second  and  equally  important  problem  was  the  aero-elastic  instability  of  the  structure 
(either  open  or  closed  loop)  of  the  original  design  [3,  Arthurs].  In  correcting  the  air  vehicle’s 
response  to  atmospheric  turbulence,  it  was  necessary  to  modify  the  planform  and  reconfigure  the 
surfaces  such  that  the  control  system  could  effectively  decouple  the  flight  control  harmonics 
from  the  first  structural  vibration  mode,  shown  on  the  left  side  graphic  in  Figure  3-7. 


3.3.3. 1  Baseline  Change 

Based  on  the  serious  nature  of  the  problem  and  faced  with  the  likelihood  of  significant 
revision  to  the  baseline  configuration,  the  Northrop  program  manager  ordered  a  number  of 
actions: 

.  The  Flight  Controls,  Aerodynamics,  and  the  Configuration  groups  were  directed  to 
study  alternative  control  configurations  that  would  provide  adequate  control  and  to 
provide  the  necessary  level  of  gust  load  alleviation. 

•  A  structures  design  “Red”  team  with  members  from  all  three  airframe  contractors, 
nationally  renowned  experts  in  structures,  and  in  concert  with  A/V  S/E  &  WSE 
groups,  was  tasked  with  reviewing  the  structural  arrangement  and  proposing 
alternative  approaches  to  alleviate  the  poor  internal  load  distribution. 

•  All  program  elements  were  tasked  to  review  all  existing  concerns  and  potential 
alternatives  to  ensure  that  potential  future  change  requirements  were  not  overlooked. 

The  response  to  these  directions  was  a  multi-pronged  examination  by  the  WSE  and  A/V 
SE  WBS  task  teams,  with  support  from  the  other  teams  as  required,  to  identify  all  existing 
problems  or  concerns  and  generate  and  evaluate  potential  solutions.  A  daily  stand-up  meeting 
provided  status  and  further  direction  from  the  Northrop  program  manager.  The  concerns 
identified  by  the  teams  included: 

•  Insufficient  primary  control  power  under  severe  gust  conditions 

•  Poor  load  transfer  from  the  outboard  wing  inboard 

•  High  risk  of  fatigue  and  single  point  failure  problems  for  the  load  path  around  the 
engine  inlet  ducts 

•  High  risk  inlet  configuration  due  to  an  internal  vane  for  engine  face  RCS  masking 
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•  Severe  high  angle  of  attack  static  and  dynamic  instability  due  to  the  effects  of  the  full 
span,  sharp  leading  edge  of  the  wing. 

3.3.3.2  Controllability 

The  flight  control  system  for  the  B-2  had  the  dual  function  of  controlling  the  aircraft’s 
flight  path  and  providing  active  gust  load  alleviation.  The  analysis  results  in  early  1983 
indicated  adequate  aero-elastic  control  margins  in  smooth  air,  but  insufficient  control  power  to 
achieve  the  required  level  of  gust  load  alleviation.  Since  the  trailing  edge  controls  provided  both 
pitch  and  roll,  this  affected  both  the  pitch  and  roll  control  margins.  Solving  the  controllability 
issue  would  require  moving  or  adding  pitch  controls  inboard  of  the  wing  first  bending  node  line, 
namely,  inboard  of  the  trailing  edge  notch.  Alternative  arrangements  were  generated  for  analysis 
and  rapid  low  speed  wind  tunnel  evaluation.  The  inboard  wing  trailing  edge  area  dominated  by 
the  engine  exhaust  was  considered  unsuitable  for  adding  controls.  The  remaining  span  of  the 
baseline  planform  could  not  provide  the  necessary  control  effectiveness.  It  was  detennined  that 
modification  of  the  trailing  edge  by  addition  of  an  extra  notch  would  accommodate  new  inboard 
control  surfaces.  Alternative  control  surface  arrangements  were  tested  in  the  wind  tunnel  and  on 
the  RCS  test  range.  By  the  first  of  May  1983,  the  testing  confirmed  a  configuration  that 
provided  both  high  control  effectiveness  and  low  RCS  risk.  The  new  inboard  controls  provided 
control  effectiveness  for  both  pitch  and  roll  functions  while  the  outboard  control  surfaces  would 
be  utilized  to  primarily  augment  low  speed  roll  control.  The  new  control  scheme  provided  a 
balance  of  control  power  for  maneuvers  and  effective  gust  load  alleviation. 

The  structural  load/flight  control  analysis  of  the  gusts  input  revealed  the  aircraft’s  pitch 
instability  yielded  an  open  loop  time  to  double  amplitude  at  these  conditions  on  the  order  of  100 
milliseconds.  This  necessitated  an  immediate  response  from  the  control  surface  and  resulted  in  a 
derived  requirement  to  provide  large,  high  rate  surfaces.  It  was  detennined  that  the  no-load  rate 
for  the  large  inboard  controls  should  be  100  degrees/second  which,  coupled  with  their  large 
hinge  moments,  would  require  adding  an  additional  hydraulic  pump  to  each  engine  (two  pumps 
per  engine).  This  also  necessitated  a  change  to  the  air  data  system.  Since  the  feedback  from  the 
measured  air  vehicle  angle  of  attack  was  crucial  to  gust  load  alleviation,  the  air  data  system  was 
moved  closer  to  the  aircraft  leading  edge  to  reduce  the  sensing  time  delay. 

An  additional  controllability  issue  was  a  low  speed  lateral-directional  cross  coupling 
concern  due  to  development  of  leading  edge  vortex  flow  at  high  angles  of  attack  that  caused 
decay  in  outboard  control  surface  effectiveness.  Aerodynamics  indicated  that  leading  edge 
rounding  could  alleviate  the  situation  and  the  LO  engineers  were  asked  to  examine  the 
possibility.  They  indicated  a  theoretical  basis  for  acceptance  of  the  change  as  long  as  the  edge 
was  sharp  at  the  tip  and  center.  That  feature  is  readily  seen  in  the  airplane  today.  After 
experimental  verification,  a  wing  leading  edge  shape  was  developed  and  accepted  which 
inhibited  vortex  formation  and  maintained  flow  energy  over  the  outboard  aileron.  This  was  an 
enonnously  important  change  to  the  aerodynamics  and  stability  and  control  of  the  vehicle 
because  it  provided  a  piecewise  linear  set  of  stability  derivatives  for  the  control  systems 
designers. 

3.3.3.3  Inlet 

An  ongoing  problem  with  the  baseline  configuration  inlet  was  a  requirement  for  an 
internal  vane  to  mask  engine  face  from  radar  detection.  The  vane  design  had  started  as  a  thin 
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structure  with  a  RAM  coating.  Better  understanding  of  its  loads  environment  resulted  in  a 
change  to  a  honeycomb  radar  absorption  structure  (RAS)  design  of  increased  thickness.  The 
enlarged  vane  and  added  support  struts  impacted  both  inlet  pressure  recovery  and  inlet  distortion 
characteristics.  RCS  testing  also  indicated  marginal  shielding  performance  from  the  vane.  The 
vane  configuration  was  becoming  an  intractable  design  and  manufacturing  challenge. 

A  particularly  brilliant  inlet  analyst/designer  was  brought  in  to  review  the  problem  and 
recommended  a  duct  shape  of  more  aggressive  curvature  to  provide  engine  face  masking  without 
the  need  for  a  vane.  Testing  of  this  design  showed  satisfactory  RCS  characteristics  and 
significantly  improved  inlet  performance.  The  serrated  inlet  leading  edge  geometry  was  also 
revised  from  a  “V”  shape  to  a  “W”  shape  to  reduce  inlet  distortions  from  the  inlet  notches  under 
certain  conditions.  This  change  also  reduced  RCS  at  certain  aspects.  The  revised  lip  and  duct 
geometry  resulted  in  an  aft  shift  of  the  inlet  and  effectively  decoupled  the  inlet  design  from  the 
wing  box  forward  spar  structure. 

3.3.3.4  Structural  Arrangement 

The  three-company  airframe  design  team  was  tasked  with  examining  improved  load  path 
balancing  alternatives  and  other  means  of  reducing  the  weight  and  risk  impacts  of  the  baseline 
structure.  The  primary  problem  was  the  wing  carry-through  structural  load  path.  The  outboard 
wing  box  mated  to  a  forward  box  structure  outboard  of  the  inlet  but  the  load  in  the  box  had  to 
transfer  to  the  box  rear  spar  and  into  spar  caps  above  and  below  the  inlet  duct  before  mating  to 
the  weapons  bay  bulkhead.  A  derived  design  requirement,  arising  from  system  requirements 
flow-down  analyses  by  the  WSE  group,  raised  the  additional  issue  of  avoiding  single  point 
failures  due  to  enemy  fire.  The  design  team  generated  a  general  recommendation  that  the  single 
spar/bulkhead  carry  through  structures,  forward  and  aft  of  the  weapons  bay  should  be  replaced 
by  a  more  structurally  efficient  box  arrangement  extending  from  the  outboard  wing  to  the 
centerline  both  ahead  of  and  aft  of  the  weapons  bay.  The  change  in  planform  required  to  achieve 
this  controllability  allowed  more  room  outboard  of  the  engine  bays  to  distribute  the  load  path 
fore  and  aft  but  the  primary  challenge  was  generating  space  for  a  forward  box  structure  across 
the  centerline. 

Theoretical  RCS  studies  indicated  the  potential  of  reducing  the  chord  of  the  RAS  edge 
structure  without  sacrificing  RCS  performance.  This  was  rushed  to  experimental  verification 
and  proven  acceptable  allowing  the  cockpit/windshield  to  move  forward.  The  direction  at  PDR- 
1  to  provide  space  and  primary  structure  provisions  for  a  potential  third  crew  member  had 
required  creation  of  an  aft  avionics  bay,  aft  of  the  weapons  bay,  to  accommodate  avionics 
displaced  by  the  third  crew  member  volume.  A  byproduct  of  the  controllability  changes  was  a 
reduction  in  gust  induced  vertical  accelerations  at  the  crew  station  which  provided  acceptable 
ride  qualities  without  the  baseline  crew  station  isolation  pallet.  The  reconfiguration  of  the  crew 
station  led  to  the  ability  to  incorporate  a  substantial  carry  through  box  structure  under  the  cockpit 
floor  ahead  of  the  weapons  bay  bulkhead.  The  revision  of  the  cockpit  lines  was  coordinated  with 
aerodynamics  and  resulted  in  improved  flow  over  the  front  end  of  the  aircraft  at  transonic  speeds 
with  an  associated  reduction  in  high-speed  drag. 

Taken  together,  the  structural  designers  were  able  to  define  a  structural  arrangement 
consisting  of: 

1)  A  forward  box  providing  a  redundant  low  risk  load  path  from  the  outer  wing, 
traversing  ahead  of  the  inlet  and  across  the  centerline  and 


43 


2)  An  aft  box  that  also  provided  good  load  transfer  out  of  the  outer  wing  panel  transiting 
around  the  engine  tailpipes  and  across  the  centerline. 

Analysis  of  this  arrangement  showed  a  more  balanced  load  distribution  of  60  percent  forward 
and  40  percent  aft.  The  forward  box  structure  also  provided  additional  fuel  capacity.  The 
primary  concern  with  the  arrangement  was  the  necessity  of  keeping  the  load  from  trying  to  go 
into  the  top  skin  of  the  inlet  and  over  the  engines  and  weapons  bays.  RCS  considerations  ruled 
out  the  use  of  either  “breathing  structure”  or  significant  bending.  Revision  of  the  upper  skin 
structure  above  both  the  engine  bays  and  the  weapons  bays  was  required  to  achieve  a  “soft”  load 
path  that  minimized  the  bending  resistance.  See  Figure  3-8. 


Figure  3-8.  Dramatic  Internal  and  External  Differences 


The  revised  structural  arrangement  required  revision  of  the  component  manufacturing 
and  assembly  for  the  aft  center  wing  and  the  intennediate  wing.  The  revised  structural 
arrangement  added  an  additional  wing  segment  to  the  Vought  Intermediate  Wing  Assembly  to 
accommodate  the  added  portion  of  the  planform  change  as  shown  on  the  right  sketch  of  Figure 
3-9  and  incorporation  of  the  centerline  box  into  the  Forward  Center  Wing  Assembly.  Overall 
weight  increase  for  the  redesigns  was  on  the  order  of  6000  pounds. 
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Figure  3-9.  Work  Share  and  Production  Changes  from  the  Reconfiguration 
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The  design  solutions  were  arrived  at  through  a  series  of  sequential  technical  decisions 
based  upon  sound  systems  engineering  analysis  and  multi  discipline  trade  studies.  After  initial 
concept  definition  and  analysis  of  the  solution,  wind  tunnel  and  observables  tests  of  multiple 
alternative  solutions  were  conducted;  modes  constriction  was  facilitated  by  the  use  of  NCAD  for 
model  design  and  fabrication,  selected  layout  definitions  of  the  structural  design  solution  and 
subsystems,  weight,  and  perfonnance  impact  studies.  The  chronology  of  these  actions  is 
captured  in  Table  3-4. 

The  cited  decisions  were  made  by  the  Northrop  program  manager,  in  consultation  with 
his  program  management  team,  while  keeping  the  Northrop  B-2  Division  General  Manager,  John 
Patemo,  and  the  SPO  current.  The  SPO’s  Technical  Directorate’s  key  staff  members  were 
working  directly  with  the  contractors’  Engineering  and  Manufacturing  staffs  during  this  period. 

Table  3-4.  Schedule  Milestones  during  the  Reconfiguration  Effort  (1983) 


Mid  February 

Identification  of  the  Problem 

Early  March 

Conceptual  Definition  of  a  new  trailing  edge/controls  arrangement 

Mid  March 

Observables  identify  reduction  in  leading  edge  RAS  depth.  Configuration  Group 
identifies  ability  to  compress  Flight  Station  length.  Observables  also  accepts  a 
prescribed  change  in  leading  edge  radius 

Mid  March 

Initiated  Low  Speed  and  High  Speed  lines  changes  to  existing  models  to  reflect  the 
trailing  edge  and  leading  edge  changes 

Mid  April 

Aerodynamics,  Observables  and  Structures  Design  recommend  shortening  the  inlet  and 
eliminating  the  vane 

Late  April 

Structures  Technology,  Structures  Design,  Observables,  and  Aerodynamics 
submit  recommendation  re  structural  arrangement 

Late  April 

Wind  tunnel  tests  confirm  control  power  adequacy 

1  May 

Authorize  development  of  a  new  OML  definition  for  the  Baseline  aircraft 

Mid-May 

Finalization  of  the  OML  and  structural  arrangement  are  established 

Early- June 

Lines  for  new  (verification)  models  released 

Mid  June 

Subsystems  requirements  updated  and  block  diagrams  revised 

End  of  June 

New  OML  definition  for  baseline  aircraft  available  to  Program 

The  Northrop  program  manager’s  decision  to  consider  this  whole  redesign  a  “contractor- 
initiated”  change  to  satisfy  the  Contract  Specification’s  requirements  was  a  major  consideration. 
This  issue  was  discussed  with  the  General  Manager  and  both  agreed  that  it  was  the  appropriate 
contractual  position,  notwithstanding  the  $1.5-  2.5  Billion  dollar  (rough  order  of  magnitude) 
estimate  of  the  program  impact  at  that  time.  Their  conclusion  was  predicated  upon  the  fact  that 
these  configuration  and  structural  arrangement  changes  provided  a  viable  solution  of  the  aircraft 
design,  and  that  the  original  design  would  not  have  met  the  original  specification  without  them. 
The  list  of  changes  included: 

•  A  control  system  design  that  could  simultaneously  control  the  gust  response  of  the 
aircraft  and  reduce  the  wing  bending  moment  impact  of  gusts 

•  A  more  balanced  bending  load  distribution  on  the  wing  (60/40  in  lieu  of  70/30) 

•  A  significant  reduction  in  local  internal  loads 
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•  A  redundant  load  path  for  the  bending  load  in  the  event  of  a  primary  structural 
element  failure  or  damage 

•  A  significant  reduction  in  the  susceptibility  of  the  structure  design  to  fatigue  failure 
during  the  life  of  the  aircraft 

•  A  solution  to  the  high  angle  of  attack  lateral-directional  coupling  of  roll  and  sideslip 

•  Decouple  the  inlet  from  the  front  spar  structural  design 

•  Improvements  in  propulsion  efficiency  and  drag  reduction 

Although  the  changes  were  implemented  on  the  Program  and  the  development  effort  was 
proceeding,  the  Division  General  Manager  also  had  his  Senior  Technical  Management 
Committee  review  the  changes  in  June  to  provide  affirmation  that  they  concurred  with  the  need 
and  the  solution  to  the  baseline  aircraft’s  problems.  Independently,  Northrop’s  Corporate  Office 
established  a  three-man  panel  of  very  senior  technical  managers  to  review  the  change.  Their 
investigation  also  concluded  that  the  new  structural  arrangement  and  the  other  changes  were 
appropriate  to  achieve  a  viable  design.  Senior  Corporate  Managers  from  the  other  airframe 
contractors  also  concurred  with  the  change. 

3.3.3.5  Programmatic  Decisions 

Concurrent  with  the  technical  management  decisions  that  the  Northrop  program  manager 
faced  was  the  choice  of  a  Class  I  or  II  change15.  As  noted,  the  Northrop  program  manager  and 
the  General  Manager  identified  the  change  as  Class  II  and  none  of  the  senior  management 
reviews  had  challenged  that  decision.  There  were  a  series  of  major  program  decisions  required 
as  well,  including: 

•  Completion  of  the  pre-requisites  for  the  “Configuration  Freeze”  milestone 

•  Ability  of  the  Program  to  attain  the  PDR-2  milestone  as  scheduled 

•  Viability  of  the  “downstream”  Program  Milestones  beyond  PDR-2 

•  Program  cost  and  funding  impact  of  the  change 

Examining  each  of  these  issues  individually,  the  Northrop  program  manager,  in 
conjunction  with  all  members  of  the  contractors’  management  team,  initiated  a  “bottoms-up” 
task  schedule  and  cost  reassessment  of  the  remaining  (“To-Go”)  work  effort  using  both 
functional  and  WBS  Task  Team  inputs  for  both  the  non-recurring  and  recurring  efforts. 
Recurring  cost  estimates  were  also  made  independently  by  the  pricing  organizations  of  all  three 
airframe  companies  using  their  parametric  databases  and  each  company  developed  independent 
parametric  estimates  of  the  non-recurring  design  effort  for  the  period  from  PDR-2  to  the  initial 
drawing  release  and  for  subsequent  changes  using  updated  definitions  of  drawing  types  and 
quantities,  and  tool  and  part  requirements. 

From  that  schedule  and  cost  reassessment,  several  things  became  evident: 


15  For  Government  controlled  baselines,  change  requests  are  classified  as  Class  I  or  Class  II.  A  Class  I 
change  proposes  to  modify  the  form,  fit,  or  function  of  an  item.  A  Class  II  change  is  needed  to  meet  a  performance 
requirement.  In  a  cost  plus  contract,  the  difference  is  funding  for  fee. 
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•  The  “Configuration  Freeze”  milestone  could  be  achieved  with  the  exception  of  two 
activities  being  carried  over  for  2  months.  The  in-depth  re-definition  of  the  “Inboard 
Profile”  and  top  level  Zone  Drawing  Layouts  depicting  equipment  and  structure 
locations  in  the  various  equipment  bays  would  not  be  initially  complete.  Also,  the 
internal  “Design-To”  loads  would  not  be  available  until  September.  The  design 
group/task  team  managers  responsible  for  these  “slippage”  elements  predicted 
recovery  of  their  schedules  prior  to  PDR-2. 

•  The  PDR-2  milestone  could  be  achieved  but  the  design  analysis  database  for  the 
vehicle  subsystems  was  questionable.  The  subsystem  task  teams  were  confident  that 
they  could  have  the  systems  schematics  and  equipment  sizing  defined,  the  penetration 
locations  established  and  the  size  of  their  routings  defined,  as  required.  The  dilemma 
was  that  this  “confidence”  was  based  on  limited  supplier  input/knowledge. 

•  The  attainment  of  the  “Interface  Control  Documentation”  milestone  was  in  jeopardy 
because  of  the  inability  of  the  vehicle  subsystems  task  teams  to  know  what  the  impact 
of  the  required  changes  would  be  on  their  suppliers’  PDR  &  CDR  milestones  and  the 
completeness  of  suppliers’  design  analyses  supporting  equipment  development  at 
those  milestones. 

•  The  CDR  milestone  was  in  jeopardy  because  of  the  lack  of  supplier  inputs  for  the 
changes  required  to  each  system  by  the  configuration  change  and  the  fact  that  many 
of  the  subcontracts  for  this  equipment  were  in  the  process  of  being  initiated  using 
specifications  that  did  not  reflect  the  changes.  Accordingly,  the  subsystem  managers 
could  not  be  sure  when  the  supplier’s  CDR’s  would  be  scheduled  relative  to  the 
Program  CDR. 

Based  on  these  findings,  the  PM  elected  to  proceed  with  the  then  current  Program 
Schedule  for  the  “Configuration  Freeze”  milestone.  However,  in  concert  with  the  other  Airframe 
Contractor  PM’s,  he  elected  to  define  a  new  baseline  Program  Schedule  downstream  of 
“Configuration  Freeze”  as  follows: 


Table  3-5.  Program  Manager’s  Schedule  Change  Recommendation 


Milestone 

Program  Plan 

Schedule  Change 

PDR-2 

Mar/Apr  1984 

2  months  later,  May/June  84 

ICD 

2  months  after  PDR-2,  June  84 

5  months  after  PDR-2,  Nov  84 

CDR 

18  months  after  ICD,  Dec  85 

20  months  after  ICD,  July  86 

First  Flight 

24  months  after  CDR,  Dec  87 

26  months  after  CDR,  July  89 

The  motivation  for  the  conservatism  implicit  in  the  Northrop  program  manager’s  decision 
was  to  preserve  the  integrity  of  a  “best  practices”  approach,  namely  retention  of  the  coordination 
between  structures  and  subsystem  design  releases  and  minimizing  fabrication  tool  changes.  The 
total  change  for  the  revised  program  was  approximately  9  months  later  than  the  Contract 
Schedule  and  the  Target  Cost  was  estimated  to  be  exceeded  by  about  $  2.3  -2.9  B.  This  schedule 
accommodated  the  concerns  of  the  status  of  the  subsystem  definitions,  procurements,  and  design 
development.  It  also  accommodated  updated  assessments  of  the  time  required  to  achieve 
completion  of  the  air  vehicle’s  production  design  using  the  3D  system  modeling  of  the 
manufacturing  process,  and  the  weight  growth  and  parts  quantity  estimates  for  manufacturing  the 
aircraft. 
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After  development  of  this  plan,  and  following  discussions  with  the  GM,  the  SPO 
Director,  and  the  senior  Technical  Advisory  Committee,  alternative  schedule  components  were 
identified  for  management  consideration.  Essentially  these  alternative  plans  examined  ways  to 
offset  or  minimize  the  schedule  and  cost  growth  issues  of  the  PM’s  plan  by  the  following: 

•  Reduce  the  manufacturing  schedule  by  eliminating  “stuffing”  of  major  assemblies 
(i.e.  installation  of  all  equipment  and  system  routings)  prior  to  shipment  to  the  Final 
Assembly  facility.  This  would  save  2-3  months  of  schedule  but  add  costs  for 
relocation  and  per  diem  expenses  of  the  traveled  work  force  plus  loss  of  efficiency. 

•  Hold  the  PDR-2  and  CDR  milestones  where  originally  planned  with  the  provision 
that  if  the  subsystem  design  was  not  mature  at  the  planned  CDR  milestone,  potential 
alternatives  to  the  downstream  Program  Plan  would  be  reviewed.  This  would  save  4 
months  of  schedule  time  but  required  the  addition  of  a  cost  contingency  for  a 
schedule  slide  at  CDR 

•  Hold  the  ICD  milestone  in  July  1984  in  lieu  of  September  1984.  This  would  save  2 
months  but  require  added  contingency  for  rework  of  “production  released”  ICD’s  and 
the  expected  resultant  design  changes. 

•  Reduce  the  historical  “change  factor”  used  in  engineering  and  manufacturing 
estimates  because  of  the  use  of  a  3D  database. 

•  Use  the  original  estimating  factor  for  production  design  drawing  development  and 
increase  the  estimate  only  for  the  increased  drawing  quantity  estimate. 

The  development  of  these  alternatives  was  completed  in  time  for  the  September  1983 
quarterly  CEO/Commander  meeting  scheduled  at  WPAFB,  OH.  Initially  the  review  focused  on 
the  configuration  changes,  the  rationale  for  each,  and  the  new  projected  system  perfonnance. 

The  alternative  plans’  assumptions  and  input  variations  were  reviewed.  There  was  acceptance 
that  schedule  slippage  might  occur,  but  it  was  believed  that  maintaining  the  original  schedule 
would  provide  the  lowest  overall  cost  and  shortest  time  to  first  flight.  The  selected  plan  had  a 
projected  cost  impact  of  approximately  $1.5  -2.0  B.  The  subcontractor  program  managers  were 
encouraged  to  use  their  “best  efforts”  to  hold  the  Contract  Program  Schedule 

3.3.4  Preliminary  Design  Review  (PDR-2) 

Following  the  resolution  of  the  Contract  Plan,  the  Program  proceeded  to  close  all  the 
remaining  technical  and  producibility  risks  required  to  support  PDR-2  except  for  the  Radar 
Antenna  performance  demonstration.  PDR-2  was  successfully  conducted  in  the  March/ April 
1984  period  with  all  requirements  satisfied.  Test  data  from  the  low  speed  and  high-speed 
verification  wind  tunnel  tests  and  from  verification  tests  on  a  new,  large-scale  observables  model 
of  the  aircraft  demonstrated  compliance  with  the  contract  specification.  At  PDR-2,  the  SPO 
added  a  requirement  for  Reliability  Design  Growth  Testing  (RDGT)  so  that  all  weapon  system 
elements  would  achieve  significant  system  reliability  maturity  by  IOC. 

The  radar  antenna  design  failure  that  occurred  during  the  risk  reduction  phase  had  been 
diagnosed  and  the  contractor  (Hughes)  had  initiated  a  series  of  risk  closure  activities,  which  were 
presented  at  PDR-2.  At  the  completion  of  those  closure  activities  (August’84),  the  antenna 
performance  and  its  observables  characteristics  were  demonstrated  in  compliance  with  the 
contractor  team’s  PDR-2  commitment. 
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Although  the  subsystems’  WBS  Task  Teams  were  able  to  meet  the  requirements  for 
PDR-2,  the  desired  depth  of  analyses  and  vendor  design  development  supporting  the  design 
definitions  was  not  achieved.  This  became  evident  when  the  contractor  team  attempted  to  meet 
its  next  Program  milestone. 

3.3.5  Interface  Control  Document  (ICD)  Closure  Date 

This  milestone  was  originally  scheduled  for  June  1984,  but  was  not  completed  on  time. 

It  took  approximately  two  additional  months  to  satisfy  the  criteria  for  this  event.  The  major 
deficiency  was  the  lack  of  specific  data  for  the  vehicle  subsystems  caused  by  the  changes  to 
those  systems  necessitated  by  the  reconfiguration.  The  implementation  of  these  changes  was 
impacted  by  the  need  for  substantive  subcontract  changes,  even  though  letter  contract  authority 
was  utilized.  The  difficulty  was  the  need  for  specification  revisions  which  required  supplier 
engineering’s  analyses  before  making  commitments  on  price. 

3.3.6  Critical  Design  Review  (CDR) 

The  B-2  Critical  Design  Review  was  held  per  the  Contract  Schedule  (December  1985). 
The  structure  design  completion  goal  of  90%  drawing  release  was  met  but  the  subsystems  design 
release  was  only  20%  complete  versus  a  goal  of  90%.  Action  plans  to  address  these  shortfalls 
were  generated  and  incorporated  as  part  of  the  CDR  closure.  No  change  in  contract  schedule 
was  made  as  a  result  of  the  action  plans  but  there  was  tacit  acceptance  by  the  SPO  program 
manager  of  the  Northrop  program  manager’s  decision  to  revise  the  Program’s  internal  work 
plan/schedule  whereby  a  one  year  delay  in  first  flight  was  defined  (i.e.  December  1988  in  lieu  of 
December  1987). 

To  partially  offset  the  Vehicle  Subsystems  design  definition  shortfall  and  the  12-15 
months  delay  that  the  Program  was  then  projecting,  the  Northrop  program  manager  elected  to 
initiate  a  change  to  the  work  plan  whereby  the  major  assembly  stuffing  would  be  deferred  to 
aircraft  final  assembly.  This  action  reduced  the  delay  by  approximately  2-3  months  resulting  in 
the  projected  flight  date  of  March  1988.  The  actual  accomplishment  of  the  100%  release  point 
took  about  five  months.  Not  all  of  that  delay  affected  the  build  of  A/V  #1  but  it  did  impact  the 
availability  of  production  hardware  for  qualification  testing,  conduct  of  complete  system  tests  in 
the  various  laboratories,  and  the  reliability  growth  test  program. 

Leading  up  to  this  critical  review,  the  preparations  were  initiated  in  the  early  summer  of 
1985.  There  were  indications  at  this  time  that  the  subsystems  were  lagging  in  progress  to  their 
entry  criteria  for  the  review.  Numerous  discussions  were  conducted  within  the  SPO  and  with  the 
contractor  concerning  CDR  preparation  and  our  readiness  to  conduct  the  review.  The  SPO  chief 
systems  engineer,  Tim  Sweeney,  reported  to  the  principles  that  all  of  the  criteria  were  not  yet 
satisfied.  The  SPO  principals  finally  concluded  that  the  CDR  would  be  held  on  the  stipulated 
date  and  coordinated  the  decision  with  the  contractor  principles.  The  conclusion  that  the 
structure  was  sufficiently  mature  was  a  key  consideration,  with  the  objective  of  conducting  the 
CDR  and  holding  open  action  items  for  those  items  not  completed  to  the  criteria.  This  was 
consistent  with  the  decision  that  was  made  after  PDR  2  at  the  program  CEO  meeting  in  the  fall 
of  1983.  At  this  meeting  between  the  company  CEOs,  the  Air  Force  senior  general  officer  at 
Aeronautical  Systems  Division,  and  their  program  managers,  it  was  agreed  that  relieving  the 
schedule  would  remove  the  pressure  from  the  team  and  would  increase  the  risk  of  an  even  further 
schedule  slip  than  was  being  projected.  CDR  was  held  in  October  and  November  1985,  with  the 
final  wrap-up  held  on  December  5,  1985. 
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At  the  conclusion  of  the  CDR  the  entire  team  recognized  that  the  schedule  was  indeed  in 
jeopardy  and  that  first  flight  in  December  1987  was  at  risk.  The  program  debated  the  wisdom  to 
re-baseline  a  new  schedule,  construct  a  new  target  baseline  and  develop  a  new  over  target  cost 
(OTC)  profile.  The  majority  of  the  decision-makers  concurred  in  maintaining  the  current 
program  schedule  and  delaying  the  construction  of  an  over  target  baseline  until  there  was 
sufficient  maturity  to  define  a  new  schedule  with  high  confidence. 

3.4  System  Checkout/First  Flight 

The  first  flight  event  was  scheduled  to  occur  in  December  of  1987  as  an  original  contract 
milestone.  As  a  result  of  the  reconfiguration,  the  Northrop  program  office  had  assessed  at  CDR 
that  this  milestone  would  occur  in  December  1988.  The  actual  flight  date  was  6  months  later 
(July  1989).  The  Northrop  program  manager  made  the  decision  to  set  the  schedule  down  by  12 
months  by  deciding  to  incur  the  additional  costs  associated  with  the  two  airframe  subcontractors 
and  Northrop’s  Pico  Rivera  facility  relocating  their  subsystems  installation  work  force  and 
support  organizations  to  the  final  assembly  facility  for  what  was  anticipated  to  be  A/V  #1  -  #3. 
As  envisioned,  the  additive  costs  were  essentially  the  per  diem  costs  for  that  work  force  for  6 
months.  The  reality  was  that  the  time  actually  extended  until  A/V  #7  due  to  the  level  of  change 
activity  and  other  unforeseen  events  not  related  to  the  configuration  change.  Major  contributors 
to  the  further  delay;  were  the  inefficiencies  in  stuffing  the  first  aircraft,  delayed  completion  of  the 
electrical  system  installation/check-out,  the  time  required  to  perform  the  functional  system 
check-out  the  first  time  on  a  very  complex  aircraft  system,  and  the  re-assessment  by  the 
Combined  Test  Force  (CTF)  of  A/V  #1  ’s  maiden  pre-flight  test  requirements. 
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4.0  SUMMARY 

The  story  of  the  B-2  engineering  development  is  rich  with  the  trials  and  tribulations  of  a 
very  complex  aeronautical  system.  In  order  to  scope  this  case  study,  the  authors  determined 
there  were  five  top  Learning  Principles  for  the  B-2  program. 

LP  1,  Integration  of  the  Requirements  and  Design  Process:  A  key  aspect  of  the 
implementation  of  the  B-2  systems  engineering  process  was  the  integration  of  the  SPO 
requirement ’s  team  with  the  contractors  ’  design  team,  including  manufacturing,  Quality 
Assurance,  and  logistics  functionals  into  a  cohesive  program  effort.  This  facilitated  continual 
trade  studies  conducted  by  the  specialists  from  the  User/SPO  government  team  with  the  company 
specialists  to  fully  assess  the  performance  trade-offs  against  schedule,  cost,  and  risk. 

The  systems  engineering  process  of  the  B-2  development  program  was  systemic  to  the 
design  process  and  the  engineers,  manufacturing,  Quality  Assurance,  logisticians,  and  program 
specialists  from  the  customer,  User,  and  contractors  all  participated  as  equals.  Everyone 
contributed  to  the  development  of  the  requirements  and  the  evolution  of  the  design.  When  a 
requirement  was  causing  a  design  risk  that  would  manifest  itself  as  a  cost,  schedule,  or 
performance  impact,  the  team  would  construct  alternative  approaches,  the  SPO  members  would 
assess  the  change  to  performance  with  the  User  to  evaluate  the  necessity  to  achieve  full 
compliance  or  rebalance  capability.  Cost  and  schedule  alternatives  would  be  developed.  Many 
times,  the  problems  could  be  resolved  within  the  teams  or  traded  within  interfacing  capabilities. 
The  day-to-day  involvement  with  the  technical  specialists  kept  the  team  ready  to  make  rapid 
assessments. 

It  is  vital  to  control  the  specifications  at  the  proper  time.  While  the  combined  team 
developed  the  specification,  it  is  the  role  of  the  customer  to  own  and  control  the  specifications, 
but  to  be  ever  vigilant  for  cases  where  the  requirements  become  difficult  to  meet.  In  this  case,  it 
is  the  final  decision  of  the  customer  to  either  fund  the  effort  to  meet  the  specification  or  change 
it.  This  was  particularly  true  for  the  specifications  that  were  not  part  of  the  initial  contract.  The 
specifications  that  were  prepared  by  PDR  1  for  the  SPO  were  all  reviewed  for  changes  in  scope. 
But,  it  was  always  part  of  the  strategy  and  the  program  funding  to  baseline  these  specifications  as 
part  of  PDR  1.  PDR  1  was  different  from  a  Systems  Requirements  Review  (SRR)  where  the 
requirements  are  typically  reviewed  across  the  entire  system.  Rather,  this  review  developed  the 
subsystem  specifications  as  derived  from  the  top  level  specifications,  which  were  approved  and 
controlled  at  the  contract  signing.  The  strategy  to  require  the  system,  air  vehicle,  engine  and 
training  specifications  at  contract  award,  the  perfonnance  based  subsystems  specifications  at 
PDR  2,  and  the  detailed  design  specifications  at  Product  Verification  Review  was  a  factor  to  the 
success  of  the  systems  engineering  process  within  the  program.  This  was  even  true  for  the  RCS 
specification  addendum  to  the  Weapon  System  specification,  which  was  placed  on  contract  as  a 
no  cost  change. 

Beside  the  obvious  lesson  learned  from  the  efficiencies  gleaned  from  the  combined 
efforts  of  the  specialists  and  the  overall  program  philosophy  of  cooperation,  there  is  a  subtle,  but 
important  point  that  must  be  highlighted  to  caution  the  practitioner  of  the  potential  pitfalls  of  this 
strategy.  After  the  CDR  milestone,  it  is  vital  to  control  this  working  relationship.  The  effort 
from  CDR  to  first  flight  is  centered  on  manufacturing  the  parts,  assembling  the  aircraft, 
qualifying  the  components,  and  checking  out  the  assembled  system.  This  is  simply  hard  work, 
and  any  unnecessary  or  superfluous  change  is  an  enormous  and  unwanted  burden  on  an  already 
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burdensome  time  frame.  Since  the  WBS  Task  Teams  worked  so  closely  and  had  implemented 
the  design  in  conjunction  with  the  Using  command,  and  since  there  is  always  a  “better”  way  to 
implement  some  of  the  features  of  the  design,  there  is  a  constant  pressure  at  the  working  level  to 
make  enhancements.  In  order  to  control  this  culture  after  the  CDR,  all  the  Using  command 
officers  were  only  participants  in  fonnal  Technical  Interchange  Meetings  (TIM),  and  all  TIMs 
were  mandated  to  have  minutes  prepared,  signed  by  the  contractor  responsible  engineer  (RE), 
cosigned  by  the  SPO  counterpart,  and  have  an  action  item  list  for  approval  at  the  Chief  Engineer 
level.  The  engineering  leadership  continuously  stressed  the  necessity  to  control  changes  and 
make  only  “must  have  to  work”  or  safety  related  changes. 

LP  2,  WBS  Task  Teams  and  Functional  Hierarchy:  The  contract  Work  Breakdown 
Structure  (WBS)  stipulated  the  entire  program  content  and  tasking  and  the  company  organized 
the  development  effort  into  WBS  teams  responsible  to  implement  the  contract  WBS.  These  WBS 
Task  Teams  were  assigned  complete  work  packages  -  for  example,  the  forward  cen  ter  wing.  The 
systems  engineering  WBS  Task  Team  efforts  were  organized  similarly,  but  with  separate 
responsibilities,  each  reporting  to  the  Northrop  chief  engineer  or  his  deputies.  The  functional 
organizations  assigned  members  to  the  task  teams  to  assure  accommodation  of  their  program 
needs.  A  vital  distinction  from  many  of  today ’s  IPTs  was  retaining  the  WBS  Task  Team 
membership  throughout  the  functional  organizations  ’  various  management  levels.  This 
facilitated  communication,  integration,  interfaces,  and  integrated  the  functional  leadership  of 
each  of  the  company ’s  technical  and  management  disciplines  into  the  decision  process.  The 
program  management  top-level  structure  was  organized  into  a  strong  project  office  with 
centralized  decision  authority  and  strong  leadership  at  the  top  of  both  the  SPO  and  the 
contractor  organizations. 

The  WBS  task  team  construct  was  unusual  because  it  had  the  inherent  checks  to  mitigate 
against  the  tendency  to  become  independent.  Since  the  WBS  task  team  leader  did  not  own  the 
assets,  the  members  had  a  responsibility  to  their  functional  organization  to  report  and  seek 
guidance.  The  functional  leadership  instilled  a  balancing  factor  in  decisions.  The  functional 
leadership  was  forced  to  provide  assistance  to  the  project  managers,  who  had  the  mandate  to 
deliver  products.  A  strong  centralized  program  management/leadership  role  was  crucial  to 
provide  the  guidance  and  focus  for  each  company  and  for  the  integrated  program.  The  process 
could  quickly  surface  the  problem  to  the  appropriate  decision  level  and  the  program  would 
efficiently  reach  a  consensus  and  resolve  the  issue.  Awareness,  knowledge,  experience, 
consistency  in  the  work  force,  and  the  authority  to  act  were  ingrained  in  the  participants. 

One  particularly  important  and  very  illustrative  event  that  underscores  the  effectiveness 
of  the  WBS  Task  Team  effectiveness  was  a  decision  made  early-on  that  would  have  profound 
and  positive  impact  on  the  program  6  years  later.  The  Air  Vehicle  systems  engineering  group 
identified  a  manufacturing  risk  (well  prior  to  PDR  1)  for  the  potential  difficulty  of  mating  the 
various  wing  sections  during  final  assembly.  Working  in  concert  with  the  Manufacturing 
Engineering  and  Tool  Design  Groups,  the  joint  SPO/contractor  team  developed  a  plan  to  reduce 
that  risk  (and  in  the  case  of  Air  Vehicle  #2  save  the  aircraft  assembly’s  compliance  with  the 
specification)  by  designing  a  special  mating  tool  for  both  the  Intermediate  Wing  to  aft  center 
wing/forward  center  wing,  and  the  Outboard  Wing  to  Intennediate  Wing.  This  machine 
implemented  precise,  computer-controlled,  micro  adjustments  with  6  Degrees-of-Freedom 
(DOF)  of  each  of  the  major  assemblies  during  the  mating  operation. 
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LP  3,  Air  Vehicle  Reconfiguration:  The  identification  of  a  major  aeronautical  control 
inadequacy  of  the  baseline  configuration  just  four  months  prior  to  the  formal  Configuration 
Freeze  milestone  caused  an  immediate  refocus  of  the  Task  Teams  to  develop  a  substantially 
revised  design.  Within  several  days,  the  air  vehicle  task  teams  were  conducting  trade  studies, 
augmenting  their  skill  sets,  and  integrating  with  the  other  program  participants  in  a  coordinated 
effort  to  derive  an  efficient,  controllable,  operationally  useful  system.  At  the  same  time,  the 
program  elements  that  were  not  markedly  affected  by  the  change  maintained  a  course  that 
preserved  their  schedule,  but  was  sufficiently  flexible  to  include  any  potential  changes.  In  a 
program  wide  systems  engineering  effort,  the  prime  contractor ’s  program  office  integrated  the 
teams,  reviewed  their  efforts,  coordinated  the  systems  trades,  and  identified  significant  changes 
to  the  outer  mold  lines,  the  radar  cross  section  (RCS)  baseline,  all  major  structure  assemblies, 
and  all  major  air  vehicle  subsystems  requirements,  with  the  exception  of  avionics  and  armament. 
The  alternatives  were  derived  by  the  end  of  the  third  month,  the  final  choice  was  selected  by  the 
sixth  month,  and  the  seventh  month  was  used  to  coordinate  and  garner  the  approval  of  all 
stakeholders.  While  the  program  response  to  the  crisis  was  rapid  and  effective,  and  a  significant 
impact  on  the  downstream  cost  and  schedule  was  anticipated  by  the  management  team,  and  the 
technical  impact  was  predicted  by  the  systems  engineering  process,  it  was  not  predicted  to  the 
fullest  extent. 

By  the  time  the  student  has  reached  this  point  in  the  case  study,  it  should  be  clear  that  the 
true  underlying  principle  of  LP3  is  the  necessity  to  stop  all  the  baseline  effort  when  a  problem  of 
this  magnitude  arises  and  concentrate  all  efforts  on  finding  a  solution.  The  program  did  this 
well.  The  people  who  knew  there  was  a  problem  had  the  ability  to  go  to  the  appropriate  decision 
level,  the  program  manager  accepted  the  bad  news  professionally,  the  teams  put  in  place  an 
immediate  recovery  plan,  the  program  responded  quickly,  and  the  new  plan  was  developed  and 
implemented.  This  can  also  be  parsed  to  a  lower  level,  even  to  the  subsystems  and  component 
level. 

LP  4,  Subsystem  Maturity:  The  effect  of  the  reconfiguration  on  the  maturity  of  all  the 
air  vehicle  subsystems  (flight  control,  environmental  control,  electrical,  landing  gear,  etc)  was 
far  greater  than  projected.  The  subsystems  were  mostly  vendor-supplied  equipments  and  some 
were  in  the  selection  process  to  the  technical  requiremen  ts  of  the  original  baseline  when  the 
reconfiguration  occurred.  After  the  new  configuration  was  derived,  the  requirements  for  the 
subsystems  changed  to  such  a  degree  that  they  had  to  be  resized  and  repackaged.  It  took  longer 
than  anticipated  by  the  systems  engineering  process  to  recognize  the  growing  problem  of  getting 
all  the  specifications  updated  and  to  identify  the  lagging  equipment  maturity  that  resulted.  Thus, 
the  reconfiguration  required  a  second  iteration  of  the  design  requirements  and  their  flow-down 
to  the  many  suppliers  and  their  detailed  designs.  These  iterations  after  PDR-2  resulted  in  the 
vehicle  subsystems  not  achieving  their  Critical  Design  Review  (CDR)  milestone  concurrently 
with  the  structure,  but  rather  five  months  later. 

As  in  LP3,  where  the  program  concentrated  in  developing  a  new  plan,  here,  the  program 
also  constituted  a  new  plan  but  it  did  not  have  the  complete  design  and  installation  impact.  The 
program  had  several  options  such  as  moving  CDR  or  analyzing  the  subsystems  to  determine 
what  additional  resources  it  would  have  taken  to  meet  the  original  date  for  CDR  with  a  new 
baseline. 

The  configuration  change  had  a  major  impact  on  the  Program’s  conduct  in  all  aspects- 
technical,  schedule,  and  cost.  The  technical  impacts  went  beyond  the  late  completion  of  the 
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structure  and  subsystems  design.  The  subsystem  design  delays  necessitated  a  higher  level  of 
structural  changes.  This  necessitated  retention  of  more  structural  design  staff  on  the  program  for 
a  longer  period.  The  execution  of  the  subsystems  development  on  a  compressed  basis  (even 
though  not  attained)  necessitated  a  significantly  larger  staff  for  a  longer  period.  These  same 
impacts  existed  at  each  of  the  major  airframe  locations.  In  addition,  the  majority  of  the 
subsystem  suppliers  were  pressed  into  significant  overtime  usage  in  attempts  to  complete  their 
design  and  build  of  early  pre-production  units  to  support  system  level  verification  and  validation 
tests.  The  lateness  of  the  subsystems’  definitions  had  its  maximum  cumulative  effect  on  the 
finalization  of  the  electrical  circuitry  design  which  impacted  the  initial  build  of  wire  harnesses 
and  the  completion  and  checkout  of  the  aircraft.  Both  of  these  issues  became  problems  in  their 
own  right  in  final  assembly.  The  relocated  subsystem  installation  teams  at  the  final  assembly 
facility  were  less  efficient  due  to  aircraft  access,  schedule  “work-a-rounds,”  the  long  supply 
chain  from  their  “home”  facility,  and  iterative  design  changes. 

LP  5,  Risk  Planning  and  Management:  The  program  was  structured  so  that  all  risks 
affecting  the  viability  of  the  weapons  system  concept  were  identified  at  contract  award  and  were 
structured  as  part  of  the  Program  and  WBS  work  plans.  The  initial  risks  were  comprised  of 
those  “ normal  ”  risks  associated  with  a  large  complex  weapons  system  development,  as  well  as 
the  new  technology  and  processes  necessaty  to  mature  the  program  to  low  to  medium  risk  at 
PDR.  Those  in  itial  risks  were  closed  prior  to  PDR  2.  The  risk  closure  process  con  tinued 
throughout  development  and  identified  new  risks  and  continuously  identified  new  risk  closure 
plans.  Most  importantly,  the  work  associated  with  risk  closure  for  each  plan  was  integrated  into 
the  WBS  task  teams  ’  work  plans  and  into  the  Program  Plans.  These  detailed  plans  showed  all 
design,  analyses,  tests,  tooling,  and  other  tasks  necessary  to  close  the  identified  risks  and  were 
maintained  and  reviewed  as  part  of  the  normal  design/program  reporting  activity. 

The  program’s  use  of  a  disciplined,  decentralized  risk  management  program  was  a  major 
contributor  to  developing  an  integrated,  funded,  resourced  plan.  It  helped  drive  everyone  to  seek 
the  right  solution  in  the  most  efficient  manner.  Treating  Risk  Management  as  a  discipline  with  a 
definitive  process  and  locating  it  at  the  level  where  work  was  accomplished  was  a  major  success 
story.  Everyone  participated;  the  lowest  level  of  the  design  team  was  responsible  for  closure, 
status,  and  reporting.  All  the  resources  necessary  to  close  the  risk  were  incorporated  in  the 
WBS,  including  the  basic  plan  and  all  the  alternatives,  if  required.  The  Risk  Closure  Plans  were 
reviewed  at  quarterly  program  management  reviews  (QPMR)  and  the  leader  of  the  WBS  task 
team  had  to  get  the  agreement  of  all  the  participants  from  all  the  sides  of  the  program  before  it 
could  be  presented  to  the  program  management  team.  This  forced  a  major  systems 
integration/systems  engineering  activity  to  assure  agreement  before  the  results,  recommendation, 
and  alternatives  were  presented. 

Thus,  the  concept  for  risk  planning  was  unique  in  that  the  approach  was  predicated  upon 
logic  rather  than  procedures.  It  required  all  functions  to  identify  their  primary  risk  issues  (related 
to  the  product  or  the  processes  to  develop  the  product),  develop  the  logic  trail  of  data  and 
decision  points  for  resolving  those  issues,  identify  the  associated  activities  for  that  resolution  and 
only  then  develop  the  appropriate  work  plan,  schedule,  and  costs  for  accomplishing  those 
activities  and  the  remainder  of  their  functional/discipline  work  plan.  In  some  cases,  the  risk 
closure  issues  were  of  such  high  risk  that  “dual  parallel  paths”  were  developed  for  their  closure. 
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EDITOR’S  NOTE 

Having  been  involved  in  the  writing,  editing  and  review  of  five  Systems  Engineering  case 
studies,  I  must  remind  the  reader  of  scope  and  viewpoint.  Time  and  money  force  the 
management  of  these  cases  to  reflect  upon  only  a  few  (4-6)  key  points  which  the  authors  deem 
most  important.  Many,  many  more  interesting  vignettes  could  have  filled  out  the  entire 
Freidman-Sage  Matrix  for  a  program  the  size  of  the  B-2.  While  the  authors  often  found 
themselves  on  a  historical  quest  for  more  (more  information,  documentation,  interviews  and 
confirmations),  I  was  forced  to  continually  scope  the  writing  effort  to  completion. 

The  authors  and  those  interviewed  often  may  disagree  on  the  top  learning  principles. 
Clearly  author  viewpoint  and  unintentional  bias  may  find  its  way  onto  these  pages.  I  have  made 
all  attempts  to  remove  unnecessary  or  overtly  biased  statements.  Every  additional  review  of  past 
cases  would  uncover  disparate  viewpoints  and  recollections  of  facts  and/or  decisions  made  on 
those  facts.  It  was  my  belief  that  having  co-authors  on  this  B-2  case,  one  from  the  government 
and  one  from  the  prime  contractor,  would  instill  an  overall  balanced  perspective  in  the  final 
document. 

Lastly,  I  hope  that  reading  the  AF  CSE  cases,  together  with  other  case  study  materials, 
will  allow  practitioners  and  Systems  Engineering  students  alike  to  be  thoughtful  of  the  lessons 
learned  across  the  nine  concept  areas  and  three  responsibility  areas  of  the  F-S  framework.  Each 
program  has  unique  technical,  political,  and  managerial  characteristics,  so  the  lessons  first  need 
to  be  understood  in  the  unique,  historical  context,  but  can  often  be  generalized  and  rationalized 
for  current  environments. 
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APPENDIX  1:  COMPLETE  FRIEDMAN-SAGE  MATRIX  FOR  THE  B-2 


Concept  Domain 

Responsibility  Domain 

1.  Contractor  Responsibility 

2.  Shared  Responsibility 

3.  Government  Responsibility 

A.  Requirements 
Definition  and 
Management 

Northrop  was  responsible  to  develop  a  conceptual  design 
responsive  to  the  requirements  of  the  initial  study  contract. 

The  contractor  and  the  SPO  integrated  the  requirements 
process  and  the  design  process  into  one  cohesive  team.  The 
using  command,  Strategic  Air  Command  was  an  integral 
part  of  the  team  in  functionally  allocating  operational  needs 
to  design  implementation. 

The  government  funded  research  for  low  observable  aircraft, 
both  at  the  AF  laboratories  and  with  industry.  They 
established  the  need  for  a  long-range  strategic  bomber  and 
solicited  the  contractors  for  design  studies.  The  government 
prepared  and  distributed  the  RFP  and  conducted  the  source 
selection. 

B.  Systems 

Architecting  and 
Conceptual 

Design 

The  architecture  for  the  avionics  system  was  developed 
during  the  study  contract  and  the  proposal  phase.  The 
weapon  system  architecture  dictated  a  long-range  high- 
altitude  stealth  bomber  with  low  altitude  capability. 

During  the  development  of  the  avionics  defensive  systems 
trade  study  prior  to  PDR  2,  the  Air  Force  participated  with 
the  contractor  in  the  assessment  alternatives  and  in  the  final 
recommendations. 

The  Air  Force  established  basic  architectures  for  the  weapon 
system  and  for  the  avionics  for  the  contractors  to  conduct 
trade  studies  and  propose  alternatives 

C.  System  and 
Subsystem 

Detailed  Design 
and 

Implementation 

The  contractor  allocated  the  functional  requirements  from 
the  systems  specification  throughout  all  the  configuration 
item  specifications  and  computer  program  critical  item 
specifications.  The  contractor  held  design  meetings  with 
the  major  subcontractors,  engine  contractor  and  the  avionics 
suppliers. 

The  Air  Force  participated  actively  with  the  contractor’s 
design  team  in  technical  interchange  meetings  for  systems 
engineering,  for  the  subsystems,  logistics,  manufacturing, 
and  flight  testing. 

The  government  engineers  and  functional  specialists  provided 
the  contractors’  teams  with  experience  on  other  weapon 
systems  relevant  to  the  development  of  the  B-2. 

D.  Systems  and 
Interface 

Integration 

The  interfaces  between  the  subcontractors  and  the 
equipment’s  in  the  aircraft  were  organized  by  solemn  and 
assigned  to  zone  managers.  Interface  Control  Definition 
(ICD)  was  a  contract  program  milestone. 

The  air  vehicle  was  partitioned  into  zones  and  a  zone 
manager  was  assigned  to  assure  matching  interfaces  and 
installation  of  equipment  within  the  zones.  Chief  engineers 
meetings  between  the  Air  Force  and  the  three  airframe 
contractors  were  held  routinely  to  settle  interface  conflicts. 

The  SPO  managed  contracts  with  Northrop  and  with  General 
Electric.  The  SPO  established  and  funded  Air  Force  Plant  42 
at  Palmdale  CA  as  the  production  site  and  Edwards  Air  Force 
Base,  South  Base,  as  the  flight  test  facility. 

E.  Validation  and 
Verification 

Extensive  laboratories  were  used  employed  for  testing  to 
verify  integration  of  components,  subassemblies,  and 
subsystems.  A  flying  test  bed  was  used  to  prove  in-flight 
integration  of  complex  avionics  suites  prior  to  commitment 
to  the  weapon  system. 

The  Air  Force  maintained  a  presence  with  the  contractor 
team  for  all  major  ground  testing  in  the  laboratories.  During 
assembly  and  checkout  prior  to  first  flight,  the  Air  Force 
assigned  27  people  to  work  on  site  as  part  of  the  checkout 
team. 

The  Air  Force  established  a  combined  task  force  and  men 
aged  the  flight  test  program.  The  Air  Force  participated  in 
ground  laboratory  testing  and  was  responsible  for  approval  of 
all  test  plans. 

F.  Deployment  and 
Post  Deployment 

Northrop  deployed  a  team  of  engineers  and  logistics  support 
personnel  to  Whitman  Air  Force  Base. 

The  Combined  Task  Force  was  established  early  in  the 
program  and  led  by  personnel  from  Edwards  Air  Force  Base 
and  included  the  contractor  personnel.  The  team  conducted 
joint  testing  with  the  Operational  Test  and  Evaluation 
(OT&E)  community. 

The  Air  Force  established  Whiteman  Air  Force  Base, 

Missouri,  as  the  operational  base  and  managed  the  preparation 
of  the  base  for  the  arrival  of  the  operational  fleet. 

G.  Life  Cycle 

Support 

The  contractor  provided  contractor  logistics  support  in 
continuous  sustaining  engineering,  along  with  a  product 
warranty. 

.  The  Air  Force  and  contractor  team  jointly  developed  the 
supportability  strategy  for  the  program,  including  the 
warranty  philosophy. 

The  Air  Force  approved  the  life-cycle  support  strategy. 

H.  Risk  Assessment 
and  Management 

Risk  closure  plans  were  an  integral  part  of  the  program. 

They  were  proposed  by  the  contractor  during  the  source 
selection  as  a  process  to  assure  mitigation  plans  were 
integrated  into  the  work  breakdown  structure  (WBS). 

The  team  managed  risk  to  the  risk  assessment  process  with 
risk  closure  plans.  Risk  closure  plans  were  developed 
jointly  and  were  an  everyday  way  of  doing  business. 

The  Air  Force  requested  a  risk  assessment  in  management 
process  and  participated  actively  in  the  risk  closure  plan 
process. 

I.  System  and 

Program 

Management 

The  contractors’  program  management  teams  were 
organized  by  functional  specialty  with  a  project 
management  focus  for  major  subcontracts. 

The  top-level  communication  and  decision-making  process 
was  expedited  by  frequent  meetings  among  the  company 
and  AF  principles.  Decision-based  Quarterly  Program 
Management  Reviews  (QPMR)  were  scheduled  and 
attended  by  all  principles. 

The  SPO  was  organized  in  a  classic  functional  structure.  A 
project  office  was  established  to  manage  across  product  areas. 
Most  of  the  teams  that  work  on  product  areas  were  integrated 
product  teams,  with  personnel  assigned  to  their  functional 
organizations 
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Development  (FSED)  Program 

Corporate  Vice  President  for  Programs 

Deputy  General  Manager,  Aircraft  Division 

Corporate  Vice  President  for  Programs 

•  Management  Consultant,  1992  -  1995 

Hewlett  Packard  Inc.,  Northrop  Grumman  Corp.,  Visionaire  Corp. 

McDonnell  Douglas  Corp.,  Bombardier  Corp.  -  Short  Brothers  Division, 
Andersen  Consulting  Inc.  and  Aerospace/  Defense  Electronics  clients 
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•  Varilite  International  Inc.,  1995-1997 

Chief  Operating  Officer  and  Board  of  Directors  Member 

•  U.  S.  Department  of  Justice,  Expert  Witness  for  A-12  Litigation,  1998  -  present 

•  Northrop  Grumman  Corporation,  Management  Consultant,  2004  -  present 

Integrated  Systems  Sector 

Education: 

•  University  of  California  ,  Los  Angeles,  CA  1953:  Bachelor  of  Science 

Majors:  Physics  &  Business  Administration 
Honors/Awards: 

•  U.S.  Army  Commendation  Ribbon  w/  Medal  Pendant,  1955 

•  NASA,  Aircraft  Design  Award  for  B-2  Aircraft,  1989 

•  Patent  Award,  Patent  No.  Design  3 14,366  (B-2  Aircraft),  1991 

•  AIAA  Associate  Fellow,  1991 
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APPENDIX  3:  INTERVIEWS 


The  company  affiliation  and  positions  are  those  held  on  the  B-2  during  the  timeframe  of  the  case 
study.  Alphabetical  list  of  interviews  include: 

James  Bottemely,  Lt.  Col.,  Manufacturing  Director,  B-2  SPO 

Dave  Conklin,  Northrop,  Avionics  Manager 

Llewellyn  “Doc”  Dougherty,  Lt.  Col.  Deputy  SPO  Chief  Engineer 

George  Freidman,  Northrop,  Avionics  and  Chief  Technical  Officer 

Joseph  Keith  Glenn,  Colonel,  Air  Force,  Program  Manager 

Tom  Griskey,  Northrop,  Systems  Engineering 

Chris  Hernandez,  Northrop,  System  Engineer 

Tom  Marsh,  General,  AFSC  Commander 

A1  Meyers,  Northrop,  Flight  Control  Manager 

Stanley  Richey,  Air  Force,  Financial  Manager 

Richard  Scofield,  Brigadier  General,  Air  Force,  Program  Manager 

Lawrence  Skantze,  General,  Air  Force,  Source  Selection  Advisory  Board  Chairman 

Erich  Smith,  Vought,  Test  Engineer,  Systems  Engineer,  Chief  engineer 

Henry  Spence,  Vought,  Chief  Engineer 

James  Sunkes,  Air  Force,  Survivability  Engineer 

Tim  Sweeney,  Air  Force,  Chief  Systems  Engineer 

Irv  Waaland,  Northrop,  Chief  Engineer 

Mark  Wilson,  Air  Force,  Lead  Structures  Engineer 

Howard  Wood,  Air  Force,  Structures  engineer 

Reviewers  of  the  first  draft  version: 

John  Cashen,  Northrop  Weapons  Systems  Engineering  Chief 

(and  patent  holder  with  Kinnu  and  Waaland) 

James  Mattice,  Wright  Laboratory,  ManTech  Director 

Robert  Patton,  Vought  Program  manager 

Mark  Wilson,  Air  Force  Center  for  Systems  Engineering 
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APPENDIX  4:  ASPA  RISK  REDUCTION  BRIEFING,  1979 

This  appendix  provides  a  sampling  of  the  early  trades  for  a  stealth  bomber.  These  slides, 
at  the  time,  were  originally  SECRET  -  SPECIAL  ACCESS  REQUIRED,  but  have  since  been 
downgraded  to  UNCLASSIFIED.  Most  of  the  slides  have  been  graphically  cleaned  for 
readability. 


A1»-6  — -4gfCUC  ACQCS6  nCOWWE&- 
LIMITEO  DISTRIBUTION 

unclassified 


-SPECIAL  AC'CrrS- 


LOW  OBSERVABLES  BOMBER  STUDY 


79-X066JB 


J 


UNCLASSIFIED 


NORTHROP 


STUDY  GUIDELINES 

•  MAXIMUM  TAKE-OFF  GROSS  WEIGHT  =  280,000  LBS: 

(RANGE  >3500  NM) 

•  EXPENDABLE  PAYLOAD  =  10,000  LBS 

o  CONUS  BASING 

•  REFUELING  BENEFIT 

•  WEAPON  DELIVERY  PHASE  NOT  EVALUATED 
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TARGET  COVERAGE 

GREAT  CIRCLE  DISTANCES  FROM  OMAHA 
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LOW  ALTITUDE  PENETRATOR 


EW  AVOIDANCE  BY  MINIMUM  FOOTPRINT, 
THREADED  FLIGHT  PATH, 

RADAR/IR  SAM  SURVIVABILITY  BY 
MINIMIZING  INTERCEPT  ENVELOPE, 
REACTION  TIME. 

ACOUSTIC  SIGNATURE,  EMISSION 
INTERCEPT  TRACKING  COUPLED  WITH 
Al  INTERCEPT  IS  MAJOR  THREAT.  _ 
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MAX  ALT  -1000  FT 


BOMBER  BASE  RCS  PROJECTION 


ENGINE  SELECTION  CHARACTERISTICS 

HIGH  ALTITUDE  CONCEPT 


7£-X0708 
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SURVIVABILITY  REQUIREMENTS 


LOW  ALTITUDE 

HIGH  ALTITUDE 

TALL  KING/ 
SQUAT  EYE 

MINIMUM  ALTITUDE 

RCS  < 

DISCRETE  SIDE  SPIKES 

ALT  k  60,000  FT 

RCS  < 

ALL  ASPECT,  FEW,  NARROW  SPIKES 
SWEEP  <  40° 

DETECTION 

SYSTEMS 

OTH 

SUAWACS 

RCS  < 

NARROW  SPIKES 

RCS  < 

NARROW  SPIKES 

SUSAT 

SHIELD  EXHAUST 

SHIELD  EXHAUST 

MINIMIZE  SKIN  TEMP. 

VISUAL 

VARY  FLIGHT  PATH 

CONTRAIL  SUPPRESSION 

ACOUSTIC 

VARY  FLIGHT  PATH 

SONIC  BOOM  AVOIDANCE 

RAD^R  SAMS 

MINIMUM  ALTITUDE 

RCS  < 

HIGH  SPEED 

ALT  2  65,000  FT 

RCS  < 

HIGH  SPEED 

KILL 

SYSTEMS 

IR  SAMS 

MINIMUM  ALTITUDE 

HIGH  SPEED 

IR  SIGNATURE  < 

ALT  >  40,000  FT 

AIRBORNE 

INTERCEPT 

RCS  < 

NARROW  SPIKES 

SHIELD  EXHAUST 

IR  SIGNATURE  < 

RCS  < 

NARROW  SPIKES 

SHIELDED  EXHAUST 

HIGH  DASH  SPEED 
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TAKEOFF  WEIGHT  (1000  LB) 


LOW  ALTITUDE  CONCEPT 


7&-XOB27C 


STRATEGIC  RANGE  CAPABILITY 


RANGE  (1000  NM) 


WEIGHT  SUMMARY 


HIGH  ALTITUDE  CONFIGURATION 


WEIGHT  -  LB 

PERCENT 
GROSS  WEIGHT 

STRUCTURE 

31,500 

20 

PROPULSION 

19,400 

12 

RAM  &  CONTRAIL  SUPPRESSION 

7,800 

5 

SYSTEMS  &  EQUIPMENT 

13,300 

8 

AVIONICS 

4,500 

3 

WEIGHT  EMPTY 

76,500 

98 

PAYLOAD 

10,000 

6 

FUEL 

73,500 

R6 

GROSS  WEIGHT 

160,000 

100 

VEHICLE  CHARACTERISTICS 


FOUR  ENGINE  DESIGNS  (PAYLOAD  =  10,000  LB) 


■■ 

B-52H 

TAKEOFF  WEIGHT 

LB 

220,000 

160,000 

N88,000 

THRUST/WEIGHT 

0.29 

0.R3 

0.28 

WING  LOADING 

PSF 

78 

32 

122 

INTERNAL  FUEL 

LB 

137,500 

73,500 

298,300 

FUEL/WEIGHT 

0.63 

0.1(6 

0.61 

OPER.  WT.  EMPTY 

LB 

72,500 

76,500 

179,700 
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PERFORMANCE  CHARACTERISTICS 


FOUR  ENGINE  DESIGNS  (PAYLOAD  =  10,000  LB) 


LO  ALT 
CONCEPT 

HI  ALT 
CONCEPT 

B-52H 

UNREFUELED  RANGE 

NM 

3,800 

5,700 

8,350 

REFUELED  RANGE 

NM 

5,700 

8,900 

12,500 

PENETRATION  ALTITUDE 

FT 

250 

60,000 

95,000 

TAKEOFF  GROUND  RUN 

FT 

7,800 

1,500 

7,900 

LIFTOFF  VELOCITY 

KN 

200 

95 

170 

LANDING  GROUND  ROLL 

FT 

3,700 

1,300 

3,700 

TOUCHDOWN  VELOCITY 

KN 

125 

70 

110 

79-X090S 


FLIGHT  ENVELOPE 
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1990  LOW  OBSERVABLES  BOMBER  THREATS 


CONCEPT 

DETECTION 

SYSTEMS 

KILL  SYSTEMS 

SAMS 

AIRBORNE 

INTERCEPTORS 

LOW  ALTITUDE 

•  IMPROVED 

SQUAT  EYE 

•  OTH  RADARS 

•  SUAWACS 

•  EMISSION  INTERCEPT 

•  ACOUSTIC  SENSORS 

•  SA-3  IMP. 

•  SA-X-10 

•  SA-S  IMP. 

•  FOXBAT/ 
FENCER 

•  ADVANCED 
INTERCEPTOR 

HIGH  ALTITUDE 

•  IMPROVED  TALL 

KING 

•  OTH  RAOARS 

•  SUAWACS 

•  SUSAT  IR  DETECTION 

•  EMISSION  INTERCEPT 

•  SA-2  IMP. 

•  SA-X-10 

•  SA-5  IMP. 
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BOMBER  BASE  RCS  PROJECTION 


TECHNICAL  RISK  ASSESSMENT 

HIGH  ALTITUDE  CONCEPT 


•  PROPULSION  -  F101X  DERIVATIVE  OF  F101  ENGINE  IN  DEVELOPMENT, 

FLIGHT  TEST  IN  1981 

-  INLET  USES  TACIT  BLUE  CONCEPT 

•  AERODYNAMICS  -  BASED  ON  FLIGHT  PROVEN  FLYING  WING  TECHNOLOGY 

-  APPLICATION  OF  PROVEN  SUPERCRITICAL  AIRFOIL  TECHNOLOGY 

•CONTROLS  -  ACTIVE  CONTROLS  FOR  LONGITUDINAL  AND  DIRECTIONAL  AXES, 
INSTABILITY  WITHIN  STATE  OF  THE  ART 

•STRUCTURE  -  APPLICATION  OF  ALUMINUM  AND  COMPOSITE  MATERIALS  CONSISTENT 
WITH  USAF  SPONSORED  DEVELOPMENT 

•  RCS  -  BASED  ON  TACIT  BLUE  TECHNOLOGY  DEVELOPMENT 

•IR  -  DRY  ENGINES,  COOL  AIR  INJECTION,  2-D  NOZZLES,  SHIELDING 


ACCEPTABLE  TECHNICAL  RISK 
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CONCLUSIONS 

•  STRATEGIC  PENETRATING  BOMBER  MISSION  IS  SUITABLE  APPLICATION  OF 
.  LOW  OBSERVABLES  TECHNOLOGY 

-  MAJOR  IMPROVEMENT  IN  SURVIVABILITY  AT  LOW  OR  HIGH  ALTITUDES 

-  TECHNOLOGY  IS  COMPATIBLE  WITH  MISSION  REQUIREMENTS  AT  LOW 
OR  HIGH  ALTITUDE 

o  LOW  OBSERVABLES  BOMBERS CONFIGURATIONS  LIMITED  TO  280,000  LB 
CAN  ACHIEVE  RANGES  OF: 

-  LOW  ALTITUDE  4100  NM  (6300  NM,  REFUELED) 

-  HIGH  ALTITUDE  7000  NM  (10,700  NM,  REFUELED) 

•  FOUR  ENGINE  HIGH  ALTITUDE  CONFIGURATION  PREFERRED 

-  CAN  REACH  1002  OF  USSR  TARGETS  WITHOUT  REFUELING  (5700  NM) 

-  MINIMUM  LOW  OBSERVABLES  PENALTY 

-  SURVIVABLE,  EFFICIENT,  PENETRATION  APPROACH 

79-XOB76B 
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Appendix  5:  Selected  Text  from  B-2  SEMP 

This  appendix  contains  selected  sections  from  the  B-2  Systems  Engineering  Management 
Plan  (SEMP) 

•  Section  1  Introduction 

•  Section  3  Organization 

•  Section  4  WBS,  Baselines,  Specifications 

•  Section  4  Risk  Management 


B-2  Systems  Engineering 
Management  Plan 


15  NOVEMBER  1989 

NORTHROP 

B-2  Oiviiion 
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SECTION  1 
INTRODUCTION 


1.1  OBJECTIVE 

The  objective  of  this  SEMP  Is  to  provide  a  management  guide  for 
Identifying  and  accomplishing  the  systems  engineering  functions  within  the 
B-2  program  and  to  provide  the  process  for  improved  horizontal  Integration 
across  organizational  boundaries.  The  SEMP  allocates  systems  engineering 
functions  to  appropriate  elements  of  the  B-2  Division.  The  SEMP  describes 
technical  program  planning  and  control,  formal  risk  management,  life  cycle 
cost  management,  engineering  specialty  Integration,  and  technical  performance 
measurement  throughout  the  B-2  Program.  Charters  and  procedures  have  been 
refined  to  focus  program  resources  on  the  completion  of  full  scale 
development,  the  transition  to  production,  and  the  completion  of  production. 

1.2  APPLICATION 

The  SEMP  presents  the  systems  engineering  management  disciplines  which 
define,  document,  and  control  the  requirements  of  the  B-2  weapon  system  and 
the  integration  of  the  air  vehicle  with  the  other  elements  of  the  system. 
Elements  of  the  SEMP  apply  to  selected  subcontractors  and  suppliers  for  new 
B-2  subcontracts.  New  subcontractors  are  required  to  submit  data  in 
accordance  with  the  requirements  of  the  SEMP. 

The  SEMP  focuses  on  the  assignment  of  authority,  responsibility, 
interface  control,  traceability,  and  change  management.  References  to 
command  media  are  made  In  each  section  where  supporting  information  Is 
available.  Command  media  vital  to  the  systems  engineering  process  are 
discussed  In  Section  3.10. 

Systems  Engineering  tasks,  primarily  active  for  early  phases  of  system 
acquisition,  are  not  expanded  In  detail.  Exceptions  occur  where  functional 
analyses  and  requirements  allocations  are  appropriate  in  exploring  new 
requirements  and  assessing  impacts  of  configuration  changes. 
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Because  the  B-2  Is  well  advanced  within  its  life  cycle,  the  system 
baseline  configuration  (see  4.2.6)  Is  tracked  by  Configuration  Management. 
During  the  current  phase,  test  and  transition  to  production,  the  primary 
emphasis  is  on  assuring  completeness  of  requirements  definition, 
demonstration  of  system  capability,  Integrity  of  subsystems  Interfaces, 
production  readiness,  and  confirmation  of  system  supportabl 1 1 ty . 

The  SEMP  supports  the  Integrated  efforts  for  development,  test, 
evaluation,  and  transition  to  production  which  will  successfully  transform 
the  U.S.  Air  Force  military  need  for  the  Advanced  Technology  Bomber  Into  an 
operational  B-2  weapon  system  fulfilling  that  need.  To  do  this,  the  SEMP 
must  be  properly  Implemented  throughout  the  B-2  Program. 

1.3  IMPLEMENTATION 

Systems  engineering  Is  not  just  a  special  engineering  organization;  it 
Is  also  a  set  of  essential  technical  management  tasks  which  are  allocated 
throughout  the  B-2  organization  and  assigned  to  the  most  appropriate 
organizational  departments.  All  program  personnel  participate  In  the  systems 
engineering  process.  Hence,  there  Is  a  need  for  the  SEMP  as  an  internal 
manual  and  procedural  guide  for  effective  Implementation. 

The  system  engineering  process  Is  federated  on  the  B-2  program.  The  up 
front  requirements  analysis  and  flowdown,  systems  Integration  and 
verification  efforts  are  the  responsibilities  of  the  design  Integration  or 
project  engineering  organizations.  With  the  Implementation  of  this  SEMP,  the 
B-2  program  committed  to  centralizing  the  responsibility  for  requirements 
analysis  and  flow  down  processes  for  new  major  changes  with  the  systems 
engineering  organization. 

Systems  engineering  procedures  are  described  In  many  of  the  Division 
Operational  Procedures  (DIVOPs).  Organizational  responsibilities  for  systems 
engineering  tasks  are  defined  In  the  Division  Management  Charters.  Much  of 
the  documentation  produced  by  systems  engineering  tasks  Is  described  In 
Division  command  media;  the  remaining  Items  are  being  covered  now.  Many  of 
the  systems  engineering  tasks  are  assigned  to  councils,  boards,  and 
committees  as  described  In  the  DIVOPs  and  discussed  In  Section  3.9. 


75 


794/ 1 Y 
1/9 


RAA841 1-001 B 
20  January  1992 
Page  1 -2a 
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1.4  TAILORING 

The  SEMP  Is  responsive  to  MIL-STD-499A,  "Engineering  Management,"  and  is 
selectively  tailored  to  focus  on  issues  related  to  the  completion  of  the  B-2 
full  scale  development  phase,  with  Increasing  emphasis  on  the 
transltlon-to-productlon  phase  of  the  program.  The  SEMP  focuses  on  the 
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functional  and  design  integration  aspects  of  the  program,  software-hardware 
qualification,  specification  compliance,  and  how  configuration  changes  affect 
system  performance,  affordability,  supportabi 11 ty ,  and  risk.  The  SEMP  is  a 
dynamic  document,  subject  to  change  as  the  program  evolves  and  procedures  are 
refined  by  experience  gained. 

1.5  SUMMARY 

Section  2  is  a  list  of  many  documents  which  Influence  Northrop1 s 
management  procedures.  Documents  required  by  contract  are  Identified;  the 
remaining  documents  are  used  as  guides,  at  Northrop's  discretion. 

Section  3  Is  organization  oriented.  It  describes  how  the  systems 
engineering  activities  are  assigned  and  controlled  within  the  B-2  Program 
organization.  Systems  engineering  task  allocation  is  discussed,  participants 
identified,  audit  and  review  responsibilities  presented,  and  program 
Interfaces  described.  This  Section  focuses  primarily  on  programmatic  tasks. 
Systems  engineering-related  command  media  are  discussed. 

Section  4  is  planning  and  control  oriented.  It  focuses  on  the  methods 
for  conducting  and  controlling  the  systems  engineering  management 
activities.  Procedures  are  summarized  and  responsibilities  assigned  for 
planning  and  controlling  task  assignments,  configuration  management,  risk 
management,  technical  performance  measurement,  major  subcontract  management, 
internal  and  external  reviews,  audits,  and  management  of  engineering  data. 

This  Section  also  focuses  primarily  on  programmatic  tasks. 

Section  5  is  methodology  oriented.  It  describes  the  methods  for 
performing  the  systems  engineering  process  and  how  the  B-2  organizations  work 
together  to  assure  B-2  system  integrity.  This  Section  focuses  primarily  on 
technical  requirements  tasks. 

Section  6  is  engineering  specialty  oriented.  It  identifies  the 
responsible  organization  for  each  engineering  specialty,  describes  the 
process  for  engineering  specialty  Integration,  and  summarizes  individual 
engineering  specialty  plans. 

The  appendices  Include  a  list  of  applicable  Division  Operating 
Procedures,  a  description  of  the  responsibilities  and  Interfacing 
relationships  of  the  Responsible  Engineer. 
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SECTION  3 

SYSTEMS  ENGINEERING  MANAGEMENT  .STRUCTURE 

This  section  describes  how  the  systems  engineering  activities  of  the  B-2 
Program  are  assigned  and  controlled.  This  section  focuses  on  the  management 
of  the  systems  engineering  tasks,  identifying  the  participants,  the 
responsibilities  for  audit  and  review,  and  interactions  between  Engineering 
and  non-Engi neering  organizations. 

3.1  B-2  SYSTEMS  ENGINEERING  OBJECTIVE 

The  overall  objective  of  the  B-2  systems  engineering  effort  is  to 
achieve  balance  among  system  performance  capability,  affordability,  schedule, 
producibility,  testability,  and  supportabi 1 i ty,  at  an  acceptable  level  of 
program  risk.  Affordability  analysis  considers  design  and  verification  cost, 
unit  production  cost,  and  operating  and  support  costs. 

3.2  B-2  PROGRAM  ORGANIZATION 

The  B-2  Division  President  and  General  Manager  has  the  overall 
responsibility  for  the  B-2  Division.  The  Vice  President  and  B-2  Program 
Manager  has  the  responsibility  for  the  B-2  Program,  as  shown  in  Figure  3-1. 
The  shaded  boxes  indicate  the  functional  organizations  which  participate  in 
accomplishing  the  systems  engineering  tasks. 

Because  this  SEMP  focuses  on  systems  engineering  functions  rather  than 
department  organization  and  because  the  Northrop  B-2  Division  maintains  a 
separate  document  depicting  the  Division  organization,  this  SEMP  contains  no 
organization  chart  below  the  level  of  Figure  3-1. 
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FIGURE  3-1.  B-2  DIVISION  ORGANIZATION 
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3.3  SYSTEMS  ENGINEERING  MANAGEMENT  TASK  ALLOCATION 

Systems  engineering  management  tasks  are  allocated  throughout  the  B-2 
Division  as  shown  in  Figure  3-2.  These  tasks  fall  into  two  categories  as 
defined  below. 

a.  Programmatic  tasks  are  related  to  providing  an  overview  of  the  B-2 
program  status  and  to  providing  evidence  that  the  technical 
requirements  are  being  satisfied  within  the  planned  budgets  and 
schedules.  These  tasks  are  managed  by  the  B-2  Program  Manager 
(R000),  who  delegates  the  primary  management  authorities  to  the 
Deputy  Program  Manager  for  Program  Systems  Management  (R500),  as 
illustrated  in  Figure  3-2.  Programmatic  issues  are  directed  to 
Program  Systems  Management. 

b.  Technical  requirements  tasks  are  related  to  defining  the  current 
and  future  contractual  technical  requirements  and  applying  the 
systems  engineering  process  needed  to  achieve  those  requirements. 
These  tasks  are  allocated  primarily  to  Engineering  (W000)  and  to 
Integrated  Logistics  Support  (ILS)  (L000),  although  other 
organizations  also  participate.  Technical  issues  are  directed  to 
the  organization  performing  horizontal  integration  [(1)  the 
Manager  of  the  appropriate  technical  organization  or  (2)  a 
Design/Build  Team  or  (3)  the  Office  of  Primary  Responsibility  for 
one  of  the  key  functions  or  (4)  the  Responsible  Engineer,  depending 
upon  the  circumstances]. 

3.4  B-2  PROGRAM  MANAGEMENT  (R000)  RESPONSIBILITIES 

3.4.1  Program  Systems  Management  (R500) 
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>  PROCEDURES  MAINTENANCE 


KOCO 

R000 

B000 

YOOT 

BUSINESS 
DEVELOPMENT  AND 
ADMINISTRATION 

B-2  PROGRAM 

BUSINESS 

MANAGEMENT 

TEST 

OPERATIONS 

R900 

R500 

PROGRAM 
PLANNING  AND 
CONTROL 

PROGRAM 

SYSTEMS 

MANAGEMENT 

DEPUTY 

SCHEDULE  CONTROL 
CONFIG  CHANGE  MANAGEMENT 
PROGRAM  PLANNING 
OPR  FOR  PRR 
DATA  MANAGEMENT 
PRODUCTION  TRANSITION 
PLANNING 


B-2  COST 
REDUCTION 
PROJECTS 


CONFIGURATION 
CONTROL  BOARD 


SCHEDULE  MANAGER 
FOCAL  POINT  FOR  REVIEWS 
PROGRAM  CHANGE  MANAGEMENT 
CUSTOMER  INTERFACE 
PROGRAM  COST  MANAGEMENT 
CONFIGURATION  CONTROL 
BOARD  CHAIRMAN 
PROGRAM  PERFORMANCE  MGT 
SEMP  POLICY  AND  DIRECTION 


>  BUDGETS 

•  ESTIMATE  AT  COMPLETION 

►  VARIANCE  ANALYSIS 


CONTRACTS 
AND  PRICING 


•  UNIT  PRODUCTION 
COST  ESTIMATES 
i  DEVELOPMENT  COST 
ESTIMATES  OF  CHANGE 


•  DEVELOPMENT  FLIGHT  TE 

AND  EVALUATION 

•  OPERATIONAL  FLIGHT  TES 
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FIGURE  3-2.  DISTRIBUTION  OF  SYSTEMS  ENGINEERING  MANAGEMENT 
TASKS  THROUGHOUT  THE  B-2  DIVISION 
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SUPPORT  COSTS 
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I  TRAINING  REQUIREMENTS 
»  SUPPORTABILITY  DESIGN 
REQUIREMENTS 
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PRODUCTION  INTERFACE 
CONTROL 
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FIGURE  3-4.  DESIGN/BUILD  TEAMS  AND  THE 
RESPONSIBLE  ENGINEERS 
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TABLE  3-1 II .  B-2  DESIGN/BUILD  TEAM  LIST  (SHEET  1  OF  2) 


1  AIRFRAME 

RESP 

ORGN 

1 

• 

;  3.i.i 

After  Center  Section 

W61 2 

3.1.2 

Intermediate  Section 

W61 2 

!  3.1.3 

Outboard  Wing  Section 

W61 2 

3.1.4 

Forward  Center  Section 

W610 

3.1.5 

j 

Control  Surfaces 

W61 1 

3.1.6 

Structural  Integration 

W610 

AIR  VEHICLE  SUBSYSTEMS 

! 

3.2.1 

Exhaust  Subsystem 

W540 

3.2.2 

Landing  Gear  Subsystem 

W512 

3.2.3 

Electrical  Subsystem 

W520 

3.2.4 

Engine  and  Auxiliary  Power  System 

W51 1 

3.2.5 

Hydraulic  and  Mechanical  Subsystem 

W51 2 

3.2.6 

F1 1 ght  Control  System 

W200 

3.2.7 

Fuel  Subsystem 

H51  5 

3.2.8 

Environmental  Control  Subsystem 

W51 4 

3.2.9 

Crew  Station 

W51 3 

» 

i 

AVIONICS 

3.3.1 

Avionics  Control  Unit 

W124 

3.3.2 

Flight  Management  Subsystem 

W132 

3.3.3 

Radar  Subsystem 

W121 

3.3.4 

Defense  Management  Subsystem 

W140 

3.3.5 

Controls  and  Displays  Subsystem 

W124 

3.3.6 

Navigation  Subsystem 

W121 

3.3.7 

Communication  and  Traffic  Control 

W125 

3.3.8 

Mission  Management  Subsystem 

W035 

3.3.9 

Antenna  Subsystem 

W91 4 
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TABLE  3-1 II .  B-2  DESIGN/BUILD  TEAM  LIST  (SHEET  2  OF  2) 


RESP 

ORGN 

OTHER 

3.4 

Ram  Structures 

W61 1 

3.5 

Armament  Subsystem 

W030 

3.6 

Integration,  Assembly,  and  Surface 

Treatment 

W612 

Air  Vehicle  Software  Development 

WOO  7 

SUPPORT 

6.5 

Weapon  System  Trainer 

W810 

j6.7 

Training  Equipment 

L540 

7.0 

Peculiar  Support  Equipment 

L870 

7.1 

1 

_ 

Automatic  Test  Equipment 

L680 
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SECTION  4 

TECHNICAL  PROGRAM  PLANNING  AND  CONTROL 

This  section  describes  the  systems  engineering  major  tools  to  plan  and 
control  the  programmatic  and  technical  activities  in  the  Full  Scale 
Development  and  the  Transition  to  Production  phases  of  the  B-2  Program. 
Procedures  are  summarized  and  responsibilities  assigned  for  planning  and 
controlling  task  assignments,  configuration  management,  program  risk 
management,  technical  performance  measurement,  major  subcontract  management, 
system  cost  management,  internal  and  external  reviews,  management  of 
engineering  data,  and  provisions  for  pre-planned  product  improvement. 

4.1  TECHNICAL  PROGRAM  CONTROL 

The  B-2  program  planning  and  control  of  technical  efforts  supports  five 
major  tasks. 

a.  Satisfy  the  program's  major  technical  requirements  with  acceptable 
technical,  cost,  and  schedule  risks.-, 

b.  Manage  the  technical  risks  to  produce  practical  and  producible 
desi gns . 

c.  Control  support  functions  to  operate  within  budget  constraints. 

d.  Control  inputs  to  requirements  definitions  to  preclude  expansion 
beyond  that  necessary  to  satisfy  the  Weapon  System  Specification 
requirements . 

e.  Measure  progress  toward  achieving  system  performance  objectives  by 
initiating  remedial  actions  to  assure  success:  alleviate  risk  and 
forestal 1  cost  growth. 

4.1.1  Contract  Work  Breakdown  Structure 

The  contract  work  breakdown  structure  is  a  primary  means  of  identifying 
the  tasks  to  be  accomplished,  allocating  budget  to  program  tasks,  collecting 
expenditures,  and  providing  data  for  management  control.  This  work  breakdown 
structure  follows  the  format  of  MI L-STD-88 1  and  contains  definition  and 
terminology  of  tasks  down  to  the  third  level.  The  work  breakdown  structure 
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dictionary  provides  the  basis  for  discrete  and  detailed  work  package 
definition,  budgeting,  and  scheduling  in  the  cost  account  plans. 

The  work  breakdown  structure,  when  extended  to  lower  levels  of  detail, 
establishes  functional  discrimination  among  the  weapon  system  configuration 
elements.  Responsible  Engineers  can  then  be  assigned  to  assume  technical 
responsibility  for  the  design  and  development  of  each  element.  The 
Responsible  Engineers  assure  compatible  interfaces  with  related  configuration 
subsystems  and  components.  These  assignments  form  the  basis  for  program 
control  of  technical  activity. 

Design/Build  Teams  are  designated  for  each  hardware  and  software  element 
of  the  contract  work  breakdown  structure  to  assure  that  all  engineering, 
manufacturing,  quality  assurance,  supportabi 1 i ty,  test,  and  safety 
disciplines  support  the  Responsible  Engineers  in  the  development  of  the 
assigned  designs  through  transition  to  production. 

The  work  breakdown  structure  is  also  used  as  a  spread-sheet  for  the 
flowdown  of  unit  production  cost  as  part  of  the  system  cost  management 
process  described  in  Section  4.5.  The  cost  estimates  for  the  work  breakdown 
structure  elements  of  the  B-2  baseline  configuration  are  assigned  as 
"not-to-exceed"  values  to  the  Responsible  Engineers.  These  values  are  used 
as  a  means  to  prevent  cost  growth  and  to  stimulate  cost  reduction  initiatives. 

Note  that  the  Responsible  Engineers  (Section  3.7)  and  the  Design/Build 
Teams  (Section  3.6)  are  responsible  for  Work  Breakdown  Structure  elements, 
whereas,  the  Offices  of  Primary  Responsibility  (OPRs)  are  responsible  for 
assuring  that  weapon  system  functions  are  accounted  for  in  the  weapon  system 
design  (Sections  3.5.5  and  5.4). 

4.1.2  Specification  Tree  and  Contract  Work  Breakdown  Structure  Integration 

There  is  a  correlation  between  the  specification  tree  and  the  B-2 
contract  work  breakdown  structure  (Full  Scale  Development,  AAA8100-001  and 
Low  Rate  Initial  Production,  AAA8100-004) .  The  B-2  Program  Specification 
Tree  (PAA81 10-012)  contains  a  list  of  basic  specifications  which  defines  B-2 
program  hardware  and  software  requirements.  Specifications  in  the  tree  are 
grouped  according  to  contract  work  breakdown  structure  number,  as  shown  in 
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the  example  in  Table  4-1.  Similar  correlation  exists  in  other  product  legs 
of  this  work  breakdown  structure. 

TABLE  4-1.  EXAMPLE  OF  SPECIFICATION  TREE  AND  CONTRACT  WORK 
BREAKDOWN  STRUCTURE  (CWBS)  CORRELATION 


Level 

Item 

CWBS  No. 

Specification  No. 

1 

System  Specification 

SS02000 

2 

Ai r  Vehicle 

3.0 

CP02100 

3 

Air  Vehicle  Subsystems 

3.2 

None 

4 

Landing  Gear  Subsystems 

3.2.2 

DAA3220P001 

5 

Main  Landing  Gear 

3. 2. 2. 2 

DAA3222P500 

Contracts  Change  Management  (X130)  and  Master  Program  Scheduling  (R930) 
are  responsible  for  the  initial  extension  of  the  contract  work  breakdown 
structure  and  any  modifications  to  reflect  revisions  to  the  contracts.  These 
activities  are  coordinated  with  the  affected  organizations  during  the 
contract  negotiation  process,  prior  to  release  for  internal  use.  This 
internal  coordination  process  ensures  that  the  extension  reflects  the  way 
that  the  work  will  be  accomplished,  while  being  consistent  with  MIL-STD-881 . 

Maintenance  of  the  B-2  Specification  Tree  is  the  responsibility  of 
Program  Configuration  Verification  (W090),  using  information  provided  by 
Systems  Engineering  (W410),  and  Configuration  Management  (W008).  Any  changes 
to  the  specification  tree,  along  with  changes  to  the  specifications 
themselves,  are  processed  in  accordance  with  the  change  control  system  as 
specified  in  DV  01.38.01. 

4.1.3  Cost/Schedule  Control  System 

The  Cost/Schedule  Control  System  covers  several  important  topics  which 
are  discussed  in  either  the  Work  Instruction  books  or  the  Cost  Account 
Manager  notebooks: 

a.  Tasking 

b.  Work  package  definition 
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c.  Budget  and  resource  allocation 

d.  Scheduling 

e.  Work  package  rationale 

f.  Techniques  for  evaluating  cost,  schedule,  and  variance  trends 

g.  Techniques  for  projecting  costs  at  completion  of  tasks 

h.  Work  package  planning  cycle 

i.  Work  authorization  authority  and  documentation 

j.  Budget  transfer  process 

k.  Earned-value  measurement  process 

l.  Variance  measurement  and  thresholds 

m.  Cost  accumulation  and  reporting. 

The  implementation  of  Cost/Schedule  Control  System  in  accordance  with 
DoD  Instruction  7000.2  and  the  overview  of  organizational  tasks  and 
documentation  are  the  responsibility  of  Business  Management  (BOOO). 

Individual  cost  account  plans  are  developed  by  the  Cost  Account  Managers. 
Business  Management  develops  a  report  for  budget  variances  and  a  report  for 
schedule  variances. 

Northrop' s  implementation  of  the  Cost/Schedule  Control  System  Criteria 
is  described  in  DTM  01.12.01,  "Cost/Schedule  Control  System  Description,"  and 
in  the  Northrop  documents  listed  in  Appendix  A,  Paragraph  A-2.  The  following 
DoD  documents  were  used:  DoD  Instruction  7000.2,  "Cost/Schedule  Control 
System  Criteria"  and  AFSCP  173-5,  "C/SCS  Joint  Implementation  Guide." 

4.1.4  Task  Assignment  and  Control 

The  contract  work  breakdown  structures  for  the  Full  Scale  Development 
contract  and  Low  Rate  Initial  Production  contract  identify  all  the  products, 
services,  and  data  to  be  delivered.  The  Northrop  systems  engineering  tasks 
are  included  in  the  following  legs  of  this  work  breakdown  structure:  System 
Engineering  (1.0),  Test  and  Evaluation  (2.0),  Air  Vehicle  (3.0), 

Training  (6.0),  Support  Equipment  (7.0),  and  Program  Management  (8.0). 

Boeing  and  LTV  systems  engineering  tasks  are  identified  in  elements  1.7  and 
1.8,  respectively. 
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The  extension  of  each  contract  work  breakdown  structure  down  to  the  cost 
collection  level,  in  conjunction  with  the  Cost/Schedule  Control  System, 
provides  the  primary  means  of  assigning  systems  engineering  and  other  tasks 
to  specific  organizations,  measuring  the  progress  in  accomplishing  individual 
tasks  against  assigned  schedules  and  budgets,  and  determining  variances 
between  scheduled  and  actual  performance  of  the  tasks.  Budgets  and  schedules 
are  negotiated  and  flowed  down  from  total  contract  budgets  to  individual  cost 
accounts.  A  single  cost  account  manager  is  responsible  for  the  work  packages 
in  his  assigned  cost  account.  A  responsibility  assignment  matrix  identifies 
the  specific  organization  responsible  for  each  cost  account  in  the  Full  Scale 
Development  and  the  Low  Rate  Initial  Production  contracts. 

4.2  CONFIGURATION  MANAGEMENT 

4.2.1  Purpose 

The  purposes  of  configuration  management  are  to  document  the  released 
system  baseline  configuration,  to  maintain  the  current  configuration  status 
and  accounting  records,  to  control  all  changes  in  the  process  of 
implemention,  and  to  audit  the  end  products  to  assure  that  they  are  as 
specified  and  defined  in  the  approved  data. 

4.2.2  Objectives 

The  objectives  of  the  configuration  management  organizations  are  to 
ensure  that  the  fundamental  elements  of  Configuration  Management  are 
implemented  for  each  configuration  item  during  each  phase  of  its  life-cycle 
and  to  ensure  that  the  fundamental  elements  are  compatible  with  the  Weapon 
System  Specification  and  the  Prime  Item  Development  Specifications 
throughout  the  life  of  the  program. 

4.2.3  Authority 

Configuration  Management  and  Verification  (W008)  has  the  authority  to 
perform  the  configuration  management  functions  of  configuration 
identification,  status  accounting,  audits,  procedures,  and  practices  as 
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contractually  required  by  the  Air  Force.  These  activities  are  performed  in 
compliance  with  applicable  Division  operating  procedures  (Ref:  Appendix  A, 
paragraph  A-3);  the  Air  Force-approved  Division  Configuration  Management 
Plan;  and  the  requirements  specified  in  D0D-STD-480A,  MIL-STD-483, 
MIL-STD-490,  and  MIL-STD-1521A.  Program  Change  Management  (R950)  is 
responsible  for  those  configuration  management  functions  which  control 
changes,  including  the  status  of  changes  and  potential  impacts,  ending  with 
the  incorporation  of  the  change. 

4.2.4  Configuration  Management  Requirements  Allocation 

The  configuration  management  requirements  are  allocated  to 
subcontractors  through  a  subcontractor  Statement  of  Work  and  the 
Subcontractor  Data  Requirements  List.  The  requirements  of  the 
above-mentioned  DOD  and  military  standards  are  selectively  tailored  before 
they  are  flowed  down  to  the  subcontractors. 

4.2.5  Configuration  Management  Functions 

The  fundamental  functions  of  the  organizations  responsible  for 
configuration  management  are  discussed  in  the  following  four  subsections. 

For  detailed  descriptions  of  functions  and  tasks  for  configuration 
management,  see  the  Air  Force-approved  B-2  Division  Configuration  Management 
Plan  (AAA81 10-001). 

4.2.5. 1  Configuration  Management  Primary  Organizations 

Configuration  Management  (W080)  releases  and  controls  configuration 
baseline  technical  documentation.  This  documentation  primarily  consists  of 
specifications,  engineering  drawings,  logic  diagrams,  flowcharts,  technical 
manuals,  interface  control  documents,  software  documents,  nomenclature,  part 
and  lot  numbering,  serialization,  reference  and  type  designators,  and  minutes 
of  technical  reviews  and  configuration  audits.  The  technical  documentation 
not  only  identifies  and  describes  the  functional  and  physical  characteristics 
of  each  configuration  item,  but  it  also  provides  the  ability  to  trace  changes 
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throughout  the  configuration  item's  life-cycle.  A  configuration  tracking 
system  is  used  to  document  flight-by-flight  configurations  of  each  air 
vehicle  and  its  support  equipment. 

Program  Configuration  Verification  (W090)  has  primary  responsibility  for 
configuration  audits.  The  purpose  of  configuration  audits  is  to  verify  that 
the  configuration  item  description  is  accurate,  complete,  and  has  met  program 
needs.  Program  Configuration  Verification  develops  the  detail  plans  and 
procedures  for  compliance  audits  of  subcontractors,  the  Functional 
Configuration  Audit,  and  the  Physical  Configuration  Audit  required  by  the  Air 
Force. 

Program  Configuration  Verification  provides  support  to  Engineering  and 
Quality  Assurance  during  technical  reviews  which  establish  documentation 
requirements  and  configuration  item  selection  criteria.  Technical  reviews 
confirm  that  the  development  of  the  configuration  item  has  reached  contract 
milestone  requirements. 

4. 2. 5. 2  Site  4  Configuration  Verification  and  Release 

Site  4  Configuration  Verification  and  Release  (L-W094)  coordinates  with 
the  Air  Force  and  subcontractors  on  the  implementation  of  deviations, 
waivers,  and  interface  documentation  changes.  Physical  audits,  parts 
reconciliation,  software  control,  and  deviation  and  waiver  coordination  are 
critical  elements  of  the  processes  performed  and  coordinated  with  the  Air 
Force  to  assure  accurate  delivery  configuration  documentation.  Site  4 
Configuration  Verification  and  Release  coordinates  with  Manufacturing, 
Engineering,  and  ILS  to  resolve  problems  relating  to  effectivities,  rolling 
of  dash  numbers,  and  accurate  change  documentation  for  air  vehicles  and 
support  equipment  undergoing  test. 

Site  4  Configuration  Verification  and  Release  maintains  the 
configuration  description  documentation  for  tracking  the  flight-by-flight 
configurations  for  each  vehicle  and  support  equipment  and  with  control  of 
change  activity  during  the  flight  test  program. 
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4. 2. 5. 3  Configuration  Status  Accounting  and  Verification  Reporting 
Organizations 

The  Configuration  Status  Accounting  and  Verification  Reporting  (W091, 
W092 ,  and  W093)  organizations  report  configuration  status  and  provide 
traceability  to  established  configuration  baselines  and  changes  to  the 
baselines.  During  the  Full  Scale  Development  and  Low  Rate  Initial  Production 
phases,  the  configuration  status  accounting  system  ensures  that  tasks 
resulting  from  configuration  changes  are  accomplished. 

Configuration  Management  DIVOPs  are  listed  in  Appendix  A,  Paragraph  A-3. 

4. 2. 5. 4  Program  Change  Management 

Program  Change  Management  (R950)  establishes  program  change  management 
policy.  Systems  Requirements  Management  (W411)  establishes  risk  tracking 
methodology  and  tracks  the  impact  of  changes  affecting  functional  and 
physical  characteristics  of  an  end  item.  Systems  Requirements  Management 
assures  that  the  impacts  are  analyzed  by  the  appropriate  organizations  such 
as  Engineering,  Manufacturing,  Producibility,  Materiel,  Integrated  Logistics 
Support,  Systems  Engineering,  Qual i ty  Assurance,  Reliability, 

Maintainability,  Operations,  Operational  Readiness,  and  Test  and  Evaluation. 
Program  Change  Management  monitors  risk  tracking  to  assure  that  these  factors 
are  defined  and  evaluated  before  changes  are  made  to  the  configuration  item 
and  its  interfaces.  Program  Change  Management  provides  administrative 
support  to  the  Configuration  Control  Board  by  reviewing  the  documentation  for 
completeness  and  accuracy,  preparing  the  agendas,  and  tracking  completion  of 
action  items  resulting  from  the  Configuration  Control  Board  decisions. 

The  configuration  control  process  is  responsive  to  the  Air  Force  and  the 
B-2  Division  requirements  for  change  proposal  initiation,  justification, 
coordination,  evaluation,  decision,  release,  incorporation,  monitoring,  and 
reporting. 
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4.2.6  Baseline  Management 

Configuration  baselines  represent  the  configuration  of  the  B-2  as 
described  by  appropriate  engineering  and  other  technical  documents,  formally 
designated,  and  fixed  at  specific  points  in  time.  Baselines  serve  as  bench 
marks  or  points  of  departure-  to  facilitate  the  management  of  change. 
Configuration  baselines  are  the  object  of  configuration  control.  The 
government  establishes  configuration  baselines  keyed  to  milestones  within  the 
overall  system  life  cycle.  Northrop  also  establishes  internal  configuration 
baselines  to  manage  changes  at  the  program  level. 

4.2.6. 1  Government  Baselines 

There  are  three  government-established  and  controlled  baselines; 
Functional  Baseline,  Allocated  Baseline,  and  Product  Baseline. 

The  Functional  Baseline  was  initially  established  with  the  B-2  Weapons 
System  Specification  at  full  scale  development  contract  go-ahead.  This 
baseline  was  supplemented  by  the  authentication  of  the  Training  System 
Segment  Specification. 

A  partial  Allocated  Baseline  was  established  by  the  Air  Vehicle  Prime 
Item  Development  Specification  at  full  scale  development  contract  go-ahead. 
The  allocated  baseline  will  be  completed  with  the  authentication  of  the 
development  requirements  specifications  (type  B-l ,  B-2,  B-5,  non-complex, 
systems  requirements  specification  as  contractually  required)  for 
Configuration  Items,  Selected  Critical  Items,  and  Computer  Program 
Configuration  Items.  These  documents  are  identified  in  the  B-2  Weapons 
System  Specification  and  in  Appendix  70  of  the  B-2  Configuration  Management 
Plan,  AAA81 10-001. 

A  summary  of  the  status  and  the  technical  and  maintenance 
responsibilities  for  both  the  functional  baseline  and  the  allocated  baseline 
is  presented  in  Table  4-1 I . 

A  Product  Baseline  will  be  established  for  each  Configuration  Item, 
Selected  Critical  Item,  and  Computer  Program  Configuration  Item  upon 
successful  completion  of  a  Functional  and  Physical  Configuration  Audits  of 
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4.4  PROGRAM  RISK  MANAGEMENT 

Program  risks  are  associated  with  the  uncertainty  in  achieving  program 
technical  performance,  cost,  schedule,  and  supportabi 1 i ty  goals.  Risk 
management  encompasses  risk  identification,  assessment,  analysis,  and 
closure.  Much  of  the  activity  associated  with  risk  analysis  uses  trade 
studies,  specialty  engineering  plans,  contingency  plans,  work-around  plans, 
supportabi  lity  analyses,  and  Cost/Schedule  Control  System  reports.  A 
procedural  description  of  the  risk  management  process  is  presented  in 
DV  15.01.22. 

4.4.1  Organizational  Responsibilities 

All  of  the  8-2  Program  organization  elements  are  involved  in  the  risk 
management  process.  The  roles  of  the  primary  participants  are  shown  in 
Figure  4-5.  Risks  may  be  identified  by  any  organization  including  the  Air 
Force.  The  functional  organizations  assign  a  risk  closure  manager  for  each 
risk  closure  plan.  This  assignment  includes  analyzing  the  risk,  developing  a 
risk  closure  plan,  coordinating  with  affected  organizations,  implementing 
actions  to  be  accomplished. 
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FIGURE  4-5.  B-2  RISK  MANAGEMENT  PROCESS 
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tracking  progress  and  reporting  progress  to  management. 

Monthly  reviews  of  risks  (Figure  4-5)  are  conducted  within  the 
responsible  functional  organization.  Risks  are  also  reviewed  monthly  with 
Program  Management. 

Weapon  System  Program  Integration  (R508)  is  the  B-2  Program  Risk 
Manager.  In  certain  cases  risk  plans  and  plan  closure  must  be  approved  by 
the  Air  Force.  In  these  cases  Weapon  Systems  Management  (R500)  will  review 
and,  together  with  the  Program  Manager,  approve  and  submit  the  requisite 
documentation  to  the  Air  Force. 

Each  functional  organization  maintains  its  top  issues  list  in  the 
Management  Information  Center.  The  B-2  Program  Manager  conducts  monthly 
reviews  of  each  functional  organizations  issues  and  briefings  to  assess  risk 
closure  progress.  Each  functional  organization  will  prepare  summary  charts 
(Figure  4-6A)  in  addition  to  its  normal  risk  plan  documentation. 

4.4.2  Risk  Identification.  Tracking 

Risks  are  initially  identified  as  part  of  normal  technical  reviews  and 
as  a  result  of  monitoring  the  Technical  Performance  Measures.  For  example, 
in  engineering,  weekly  project  reviews  are  held  during  which  new  risk  areas 
are  presented.  Once  a  month  the  project  review  is  dedicated  to  status  the 
highest  risk  Engineering  Issues  and  to  propose  and  select  new  candidates  for 
this  Top  Issues  List.  Similar  processes  occur  in  other  functional 
organizations.  The  functional  department  Top  Issues  are  briefed  monthly  at 
the  program  review.  Weapon  Systems  Management  (R500)  selects  the  top  program 
technical  and  business  issues  primarily  from  the  functional  department  Top 
Issues  lists.  Risk  identification  extends  to  schedules  as  well  as  technical, 
business  and  cost  issues.  DIVOPs  01.12.02  (Cost/Schedule  Control 
System-Scheduling)  and  01.33.04  (Red  Flag  Report)  specify  the  procedures  to 
be  followed.  Once  identified,  the  issue  becomes  a  subject  for  risk 
tracking.  In  case  of  functional  operating  schedules  (F0S)  a  constraint 
analysis  report  (CAR)  may  be  required  per  DV  01.12.02. 
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FIGURE  4-6.  RISK  IDENTIFICATION  AND  ASSESSMENT 
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The  intent  is  to  actively  manage  only  the  very  significant  risks  at  the 
Program  Manager  level  and  allow  each  organization  to  manage  lower  level 
risks,  with  appropriate  controls  on  closure. 

Control  numbers  are  assigned  by  the  functional  organizations  in 
accordance  with  management  information  center  (MIC)  protocol  (e.g., 
engineering  no.  E-xx)  and  each  risk  issue  is  tracked  by  this  control  number, 
as  shown  in  Figure  4-5  and  4-6A,  until  formally  closed.  Figure  4-6A  shows 
the  potential  evolution  of  an  issue  from  "emerging"  to  "program"  (technical 
or  business)  and  then  to  closure. 

Assessment  of  risks  includes  subjective  judgments  of  the  probability  and 
consequences  of  not  achieving  a  required  program  objective.  This  assessment 
results  in  the  classification  of  the  risk  as  shown  in  Figure  4-6  and  the 
designation  of  the  management  level  responsible  for  review  of  progress  made 
toward  risk  reduction  or  elimination.  Risk  analysis  includes  the  assessment 
of  the  risk  and  its  potential  program  consequences,  identification  of 
possible  risk  reduction  actions,  and  selection  of  actions  to  be  pursued  by 
the  responsible  organization.  Risk  analysis  also  includes  careful 
examination  of  the  costs  of  various  alternatives;  while  a  certain  action  may 
be  technically  preferable,  the  implementation  costs  may  be  prohibitive. 

4.4.3  Risk  Reduction  and  Closure  Plan 

Having  identified  the  approach  to  be  followed  to  reduce  or  eliminate  a 
specific  risk,  a  risk  closure  plan  is  developed  by  the  risk  closure  manager 
and  approved  at  an  appropriate  management  level. 

Risk  closure  plans  follow  a  prescribed  format,  which  includes  risk 
control  number,  risk  level,  responsible  technical  and  project  engineer,  brief 
descriptions  of  1)  the  issue,  2)  impact  on  performance,  schedule  and  cost, 

3)  closure  actions  and  milestones.  It  also  includes  flow  diagrams  and 
schedules  (DV  15.01.22).  This  common  format  is  used  for  functional  and 
program  reviews  as  well  as  for  Quarterly  Program  Management  Reviews  with  the 
Air  Force. 
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FIGURE  4-6A.  RISK  MANAGEMENT  SUMMARY 
(SHEET  1  OF  4) 
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FIGURE  4-6A.  RISK  MANAGEMENT  SUMMARY 
(SHEET  2  OF  4) 
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FIGURE  4-6A.  RISK  MANAGEMENT  SUMMARY 
(SHEET  3  OF  4) 
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FIGURE  4-6A .  RISK  MANAGEMENT  SUMMARY 
(SHEET  4  OF  4) 


